Alternate name for MONKEY pragmas

[wimvanderbauwhede]

I propose to have an alias for the MONKEY pragmas used for unsafe features.

The reason is that the term MONKEY is not descriptive. It relies on knowledge of idiomatic English to understand its purpose ("monkey around", "monkey see …"). The proposed term UNSAFE-FEATURE is self-describing: the action allowed by it is potentially unsafe. It is also in line with other languages: Rust (unsafe keyword), Go (unsafe package), Haskell (unsafePerformIO).

I propose to the following aliases:

use UNSAFE-FEATURES; # all of them
use UNSAFE-FEATURE-TYPING; 
use UNSAFE-FEATURE-EVAL; 
use UNSAFE-FEATURE-INTERNALS;  # I prefer "internals" over "guts" as it is less visceral

[habere-et-dispertire]

I support this pragmatic suggestion which also avoids a term whose surface representation can be construed as speciesist.

[patrickbkr]

I think the question of use of terms is a broader topic in Raku and I think it would be wise to find a general answer. Raku (and Perl as well) has a long tradition to use non-technical and sometimes slang terms to describe things. Some examples are: '"Texas operators", "slurp", "spurt", "bless", "punning".

[CIAvash]

May I add "Function 'x' needs parens to avoid gobbling block"?

[gfldex]

None of the MONKEYs are inherently unsafe. They may have consequences the user has to take into account tho. The term MONKEY was choosen deliberately because monkey-typing is a well established term in dynamic languages.

Ideology (and taste) have changed back and forth over the decades. If we want to have a 100-year language, we will have to accept that phrases go out of fashion and the meaning of words changes. Do we want to update CORE every 30 years to keep in sync with natural language? And what flavour of English do we base that on?

I'm from eastern germany and was forced by my colonial masters to learn Russian. My Ideology-Warning-Light is blinking like mad with this proposal.

[lizmat]

@patrickbkr "Texas operators" was removed just before the release in 2015, if I remember correctly. I don't believe "punning" exists in Perl. "spurt" was chosen after a long deliberation. "slurp" and "bless" were indeed inherited from Perl. Personally, I wouldn't mind changing "bless" to "instantiate".

[patrickbkr]

@lizmat I think there are many more examples. (chomp, chop, die, Mu, Cool, KnowHOW, Dateish, Stringy, ...). My point is that this is not a question of a limited set of offending names we may or may not want to rename, but a question of culture we inherited and cultivate. Punning is an essential part of the fun the devs have on IRC. When choosing between two equally descriptive words to describe a thing, the Raku devs will usually choose the punnier one. Is this for some of us a part of -Ofun? Do we want to continue cultivating that culture or do we want move on? Moving on could mean setting the bar higher for understandability / obviousness and has the potential to lower the bar for non-native speakers.

I believe there isn't an easy answer. I think in this case it really is tradeoffs. We can't have our punny-funny-Ofun world and at the same time be serious and scientific (i.e.no fun allowed). I think this relates to the discussions that come up from time to time around Camelia and the non-professional looks of it some people dislike.

[lizmat]

Do we want to continue cultivating that culture or do we want move on? Moving on could mean setting the bar higher for understandability / obviousness and has the potential to lower the bar for non-native speakers.

Ideally, I think we would want to do both. Now, in the case of bless, in Perl it means adding extra information to an existing data structure. In Raku, it means to instantiate an object of a given class. These are subtly different things in my opinion, so renaming bless to instantiate I think would make sense from understandability / obviousness point of view.

[thoughtstream]

I don’t wish to comment on the principle of aliasing these names, just on their linguistic affordances.

The proposal is:

use UNSAFE-FEATURES; use UNSAFE-FEATURE-TYPING; use UNSAFE-FEATURE-EVAL; use UNSAFE-FEATURE-INTERNALS;

I’d suggest that having both ...FEATURES and ...FEATURE... is going to lead to (trivial but persistent) aggravation when people inevitably use the wrong one.

If this proposal is adopted, I’d suggest:

    use UNSAFE-FEATURES;
    use UNSAFE-FEATURES-TYPING;
    use UNSAFE-FEATURES-EVAL;
    use UNSAFE-FEATURES-INTERNALS;

...or maybe even make the feature selectors into arguments:

    use UNSAFE-FEATURES :ALL;
    use UNSAFE-FEATURES :TYPING;
    use UNSAFE-FEATURES :EVAL;
    use UNSAFE-FEATURES :INTERNALS;

...so that one can select multiple unsafe features in a single call:

    use UNSAFE-FEATURES :TYPING, :INTERNALS;

[wimvanderbauwhede]

I like that proposal a lot:

        use UNSAFE-FEATURES :TYPING, :INTERNALS; # or :ALL

[bbkr]

Linguistic stunts were the the thing that caught my attention waaaaaaaaay back when I was learning Perl. And I like those blesses, chomps, "manipulexity and whipuptitude", Cools, sinks...

• They give Perl / Raku distinct vibe.
• They act like mnemonic techniques needed in such complex language. For me "monkey typing" is far easier to remember than "unsafe features" despite the fact that I'm not native English speaker.

I'm mildly against change. Creating formal/informal aliases may bring performance penalty in some areas and make learning Raku more difficult because aliases will bloat documentation and introduce even more coding standards in ecosystem.

[finanalyst]

Humour is a good thing: it helps memory and it gives a subject some emotion. Puns are inherently linguistic and so seem opaque to a person for whom English is not a first language. I do like Monkey-typing because of the allusion to the three wise monkeys who 'See no evil', 'hear no evil', 'speak no evil'. The reference is from Japanese culture originally. There is also an emoji https://emojipedia.org/see-no-evil-monkey/

So 'Monkey-See-No-Eval' is funny, because Eval is evil.

"UNSAFE-FEATURES" ? It might be more 'descriptive' in some dry super-sensible way. But the impact of EVAL being Evil is just too good to lose.

[wimvanderbauwhede]

@finanalyst I am aware of the cultural origins. I understand the Japanese pun 見ざる・見猿 which is of course lost on non-Japanese speakers. I also know about the problematic emoji. The Confucian origin of the phrase is about sin, not evil. What Confucius' teaching says is that you should not commit sins because you observe others commiting sins. Which is a long way from saying that eval() is an unsafe operation. And I am not proposing to remove anything, just to have an alias.

[finanalyst]

@wimvanderbauwhede It's not the cultural origins that matter, but humour. The humour may not be apparent to everyone, but its not like 'MONKEY' is going to be misinterpreted. Anyone who comes across the term, which is clearly explained in the documentation, is going to remember it, whether it offends their sensibilities or tickles their whimsy. And surely is not the remembering bit a 'good' thing?

I wonder whether you have come across the Wombles of Wimbledon Common in the Tests documentation. Even in the UK, the cultural reference is barely understood now. But all the cultural references in the Tests page make it one of my favourite pieces of documentation. It could have been written in a much drier and precise way. I don't think it would have been better.

[2colours]

May I add "Function 'x' needs parens to avoid gobbling block"?

Oh, and of course "dwimmy end of hyper operators", but also "spesh", arguably.

@patrickbkr opened up a broader topic/narrative. I usually wouldn't talk about it because at the end of the day, it's not a big deal to use any consistent terminology you are given. (It's a whole different problem that even terms like "list", "array" and especially "container" are often thrown around without proper justification or even definition...)

If one needs to take a stance on Raku's terminology, well... I think it could hardly get any worse, really. Perhaps if it even was offensive... Vague, arbitrary, insider joke names all around. Some "good examples" were already noted, and the MONKEY stuff isn't even remotely the worst in my opinion... Dateish, KnowHOW (this is a zero out of ten), HOW-WHAT-WHY in general but also "dwimmy" - good luck looking them up or grasping what they mean.

I think they are problematic for two reasons:

1. They are severely impractical. Giving something a name that is neither descriptive, nor properly searchable doesn't seem to be justified by the amount of fun they give to a rather closed set of people. Really, it's not fun at all to try to figure out how Dateish is not Date, what on earth dwimmy tries to mean or what does KnowHOW know how to do. Then go back, retry, and again find they don't make much more sense than zodiac signs.
2. I'm generally with @gfldex on the "Ideology-Warning-Light" concept - however, I find it a bit more than ironic that the programming language that deliberately welcomes and encourages diversity, carries this size of inside joke baggage, often in a downright anglocentric fashion. A significant proportion of us here in this discussion aren't even native speakers of English... From my perspective, we are using English simply as a given common protocol, to go out of one's way in order to make an umpteenth anglo pun goes against the vision Raku offered for me.

Will things change drastically, with or without my rant? Probably not. Perhaps at least error messages shouldn't use "dwimmy"... What matters more is rather the principle: let's not treat the Raku language as a sandbox for a handful of people. It's important to keep in mind that most potential users may not want to adapt to a whole isolated(-ish :P) culture; Raku won't automatically turn into another boring language just by letting outsiders manage without all the "funny Raku legacy".

[duncand]

1. They are severely impractical. Giving something a name that is neither descriptive, nor properly searchable doesn't seem to be justified by the amount of fun they give to a rather closed set of people. Really, it's not fun at all to try to figure out how Dateish is not Date, what on earth dwimmy tries to mean or what does KnowHOW know how to do. Then go back, retry, and again find they don't make much more sense than zodiac signs.

What would you propose instead of Dateish for the name of that role (maybe Datelike)? It seems to be just the right level of specificity, similar to a Date but not generic enough to include DateTime or the like. I realize its not the best language but not every type name lends itself to the cleanest abstractor like say "fractional" could be a role for "fraction" etc so we kludge a bit.

[thoughtstream]

As this discussion appears to be on-going, here are a few further (mostly historical) points to consider:

• Having learned our lesson with Perl, one of our fundamental design criteria for Raku was to avoid providing synonyms for constructs. Hence, unlike Perl, Raku doesn't offer for/foreach or eval{}/try{} or <>/readline or <...>/glob. That still seems like a good policy to me. So, if we're renaming MONKEY stuff, I think it should be a complete rename, not a mere aliasing.

• The name MONKEY was indeed chosen both because of the existing concept of "monkey typing" and because of the pun of "See no eval" and because of the idiomatic English verb "to monkey" meaning to mess around with something that perhaps one doesn't fully understand.

• But MONKEY was also specifically chosen as a disaffordance: so that coders actually would feel a little embarrassed and unprofessional to have it appear in their code. Likewise SEE-NO-EVAL and GUTS. In other words, these terms are intended to make you a little uncomfortable or disoriented when they're used...so as to subtly discourage their use in the first place. In fairness, use UNSAFE might work almost as well in that respect (and use FREAKING-UNSAFE would work even better! ;-)

[patrickbkr]

Just to add my personal stance:

I do like the way things are named in Raku. I do value having MONKEYs around and that I am allowed to slurp and spurt and die. Knowing the literal meaning of these words makes it easier for me to remember them. I have a tiny rebel living in my chest. Thus I wouldn't like for us to ban parts of the culture I have come to like in the hopes that we can cater to people that believe a programming language isn't good to use if it uses the wrong words. I do value consistency and understandability. I do believe that we can strive for consistency without giving up our culture.

I do notice that having things named differently from other languages in rare situations requires to look a term up instead of understanding it from prior context. The only time I remember that happening to me was Texas Operators as I didn't know the saying that "everything is bigger in Texas" and happened to stumble upon that term before learning about the meaning. But looking a term up in the glossary or documentation isn't a big deal.

[2colours]

What would you propose instead of Dateish for the name of that role (maybe Datelike)?

Ironically enough, this requires me to go back and ponder yet another time why Date and Dateish exist as separate things in the first place - and find that there is no clear reason. From all I understand, Dateish only exists to offer Date semantics as a role... so eventually, -ish is the role marker? 🤔I mean, okay, if so then let's do it consistently, this is not the end of the world.

However, "HOW-WHY-WHAT", "KnowHOW" in particular and "dwimmy" - also, I forgot to mention "Cool" which is cool indeed, among many things in Raku but makes no sense either on its own or as "convenient OO loop" - are still just there, with no context, in a completely arbitrary fashion.

Do notice that I'm absolutely not naming the same things as @patrickbkr for example. slurp, spurt and die, these are all simple and understandable concepts. However, hyper metaoperators are too complex to pass funny-sounding, vague, underdefined words around. Similarly, the metamodel is too important to be hidden behind the completely undescriptive HOW name. Yes, I read @raiph's great article about the metamodel, or well, at least one great article - and no, "KnowHOW" still makes no sense for a name, not the slightest. "Singularity", "GodModel", "SelfModel" or even "BigMeta", these are fairly arbitrary and punny names but I think any of these random names I quickly came up with make magnitudes more sense than the "HOW" terminology and the word "Know" attached to it.

If we manage to clarify Stringy-Dateish-etc. names as role names - the situation still won't become optimal because there are other role names with no similar hint: Blob, Buf, Associative, etc. - then that's one down. I think that in itself (i.e making clear that this "ish names" are base roles for common classes) might be an important step forward, without having to change anything about the language itself.

I also agree that it's silly to avoid a language just because of "using the wrong words". Having said that, I think "we", as in the Raku community, need to humble down a bit about the appeal we are making to the outer world. We are in no position to say "well, we don't care about first impressions and superficial people". I think the renaming of the language is - partially - an acknowledgement of this. Letting some of the worst names go, or even just acknowledging that they are quite objectively bad names and compensate for that wherever possible, wouldn't mean "destroying the Raku culture" or anything like that. (It's weird to feel like the progressive one within this community, really. :D)

Overall, I'd like to point out that my most important point is not about the (imo) bad naming conventions - it's much more about the "insider joke culture" that I think is bad both for marketing and the declared Raku values. Don't get me wrong when I say "Raku as a language and a community is hardly approachable". The people are helpful and overall nice, same goes for the language. But they both require a very serious sacrifice from the newcomer. And no, this isn't simply because Raku is a big language, not at all. This is because Raku was designed with a very specific, unique and complex vision in mind and one needs to basically buy into this vision - along with the "memes" - in order to successfully use the language.
As long as we don't have a "killer feature" in the most classical, boring, marketing-management sense, we are facing a dichotomy: either we lower the "cultural entry point" of the language and the community - or we accept that the main offer of Raku is the vision itself and the success of the language is completely determined by the popularity of this "meme" (in the Dawkinsian sense, just like a religion is a "meme") over time.

[2colours]

For the specific topic of this issue: I think "rename over alias" is a dangerous policy at this point - because there are strong arguments against renaming (compatibility) that wouldn't apply to an alias. Also, as we all know well... an alias might turn into the new name over time; perhaps this can be handled at a new version.

Having said that, I really don't have strong feelings about the MONKEY pragmas, I don't think I ever used them. Again, it's rather the principle that we aren't gonna achieve any changes if we think in extremes.

[codesections]

My ¢2 on this very interesting discussion:

• On Dateish specifically: In theory, I like the idea of ish as a role marker – the problem is that Raku uses y as the role marker elsewhere: Setty, Baggy, Mixy, Proxy – oh, wait, no, not there :no_good:. As Proxy hints at, y is kind of ambiguous and I wish we'd been more consistent in using ish (e.g., Setish). Though ish and y aren't the only role endings…there's also Positional/Associative, etc. In the absence of consistency, maybe the docs could be clearer about what terms Raku uses to indicate roles? Is there a (grammatical) term that covers all of those words. (I know "adjective" does, but feels a bit vague…)
• On "rename over alias": I think @2colours makes a good point about not breaking code. I'd like to point out a middle ground, however: we can rename something but make the old name an alias – but an alias that triggers a depreciated warning. That wouldn't break any code but would avoid the "two names for the same concept" problem that @thoughtstream pointed out. [I'm not necessarily endorsing this approach in every case; just pointing it out as an option]
• On Raku's accessibility: I believe that the points @2colours brings up deserve serious consideration; after considering them seriously, I currently disagree. Imo, Raku does a good job of using accessible/non-inside-joke language for most concepts – especially most concepts that most userspace Raku code needs. (This is part of the "Many acceptable levels of competence" idea.) But (again, imo), Raku also does a good job of using unfamiliar words to signal that something difficult/weird is going on – sort of a warning sign to users who are stumbling into the deep end. For example, it's possible to use Raku for years without needing to use any of the HOW/WHAT/WHY family – but if a user is going to mess with them, they need to understand the MOP at a reasonably deep level. And I view the odd names as a good signal of that.

But all that is just, like, my opinion, man.

[2colours]

@codesections it's really good to see you around, (I have to say... I hope we will meet more often in Raku online spaces in the forecoming months.)

Let me disagree with the point about accessibility - not on the principle because that sounds fine; on the details.

"gobbling block" and "dwimmy end of hyper metaoperator" are in the userspace - to make it worse, they are in error messages. It feels like a bad gamble to put insider lingo inside error messages, of all places: that should be the most defensive place because that can cause the most headaches to a user. Give them an error message that they don't understand and can't even look up and well... see them explode.

Also, my problem with the "HOW-WHAT-WHY" triangle (I would argue that WHAT is fairly everyday for learning by trying, by the way) and "KnowHOW" isn't that they are unfamiliar, odd, or that they need to be "shouted" - rather that they are downright unhelpful and undescriptive, even if you know the core concept. One might say that it won't matter if you just learn the thing good enough - however, my personal feeling is that metamodel stuff is communicated so badly that it actively kept me from understanding - and all of this starts with "HOW", and basically ends with "KnowHOW". Yes, now that I feel I understand at least the core concept of the metamodel, these words can hold me back much less - but do I feel they tried to? Yes, absolutely, and this isn't such a good thing when you are already at the position that you want to learn something...

[duncand]

• On Dateish specifically: In theory, I like the idea of ish as a role marker – the problem is that Raku uses y as the role marker elsewhere: Setty, Baggy, Mixy, Proxy – oh, wait, no, not there 🙅. As Proxy hints at, y is kind of ambiguous and I wish we'd been more consistent in using ish (e.g., Setish). Though ish and y aren't the only role endings…there's also Positional/Associative, etc. In the absence of consistency, maybe the docs could be clearer about what terms Raku uses to indicate roles? Is there a (grammatical) term that covers all of those words. (I know "adjective" does, but feels a bit vague…)

I feel that there is a fundamental misunderstanding here by some people, as exemplified above.

On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A data type class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES.

This is a GOOD design for a language, which I have also repeated in my Muldis Data Language etc from Raku's inspiration.

The fact some roles end in "y" or "ish" or whatever is just a coincidence, and mainly comes from the lack of better dedicated words, which otherwise would be used in each instance, such as Positional or Associative or Stringy or Numeric etc.

We definitely should not read into "y" or "ish" being a pattern, rather the names of roles should all be individual case by case, ideally describing what something does, and in the cases under question, things like Setty etc just mean "behave like that thing".

[codesections]

On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES.

This is a GOOD design for a language, which I have also repeated in my Muldis Data Language etc from Raku's inspiration.

I agree that NOUN = class and ADJECTIVE = role would be a good rule.  The problem is that Raku doesn't consistently follow that rule (as can be seen in the list of Raku types).  That's what I meant by saying that describing role names as "adjectives" felt a bit too simple – there are lots of cases where we don't follow that pattern.

[vrurg]

I don't see a big discrepancy in using -ish vs. -y. Roughly, -ish characterizes something less tightly bound to the base term; whereas -y is more. If that loose/tight relation of a role changes over time then we're just left off with some legacy status quo.

So, Dateish is something Date-like, but not quite; and Setty is almost like Set, but not is.

BTW, it was a good exercise in English for myself and now I have a better rule of thumb as to when to use which suffix. ;)

As to Positional, Associative. Let's be consistent and use Listy... Listish??? Eh... Thanks, no! ;)

It really feels like Larry thing, more of a linguistic approach to things. While speaking we use what's better fitting the current situation, context, etc. It wouldn't be necessarily the same form of a term at any given time, we would vary it depending on circumstances. Perhaps people with a synthetic mother language do get all this better than the rest. ;)

[duncand]

As to Positional, Associative. Let's be consistent and use Listy... Listish??? Eh... Thanks, no! ;)

Nonsense! The Positional and Associative are the most optimal kinds of roles which are all about describing a kind of behavior on its own terms, and are NOT about saying "behaves like X". It doesn't make sense to associate them with List etc.

[duncand]

On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES. This is a GOOD design for a language, which I have also repeated in my Muldis Data Language etc from Raku's inspiration. I agree that NOUN = class and ADJECTIVE = role would be a good rule.  The problem is that Raku doesn't consistently follow that rule (as can be seen in the list of Raku types).  That's what I meant by saying that describing role names as "adjectives" felt a bit too simple – there are lots of cases where we don't follow that pattern.

I can see what you mean if you're talking about roles like Blob or Buf or some others.

In that case they probably should have been called Blobby and the like.

A fundamental part of the problem here, shared by Raku and many other languages, though NOT shared by my Muldis Data Language, is the conflation between types and behaviours in the same named concepts "role" or "class".

A better language design is such that a data type is strictly defined as a set of values, full stop. The definition of a type is just the enumeration and/or subset/union/etc definition etc that tells you whether a given value is a member of that type or not. And then all routines that define behavior or actions are NOT part of the type definition, but instead are external to that and they USE types. You can have libraries/modules that organize the routines that use types but aren't considered types themselves.

The problem with a lot of languages is they use the same concept name, class or role etc to describe things that are data type definitions and things that define things which work with types but are not types. These should be separate, and then each would more naturally have its own independent naming conventions.

[2colours]

So, Dateish is something Date-like, but not quite; and Setty is almost like Set, but not is.

This sounds a lot to me that ultimately there is no difference...

Again, we are back into deep analysis of English - what for, and frankly, why do we need to care this much about English of all languages? I swear, there are tons of interesting languages - actually, I have only come across languages that made more sense than English and that's still a very limited and Eurocentric vision. Anyway, I think we can admit that we are typically not linguists, neither Shakespeare, and most people (perhaps including the majority of people involved in this discussion) do struggle with these English neologisms.

Nonsense! The Positional and Associative are the most optimal kinds of roles which are all about describing a kind of behavior on its own terms, and are NOT about saying "behaves like X". It doesn't make sense to associate them with List etc.

I'm not saying that you are necessarily wrong but you cannot just make these declarations; the arguments are missing - especially since for some weird reason, Array descends from List which creates an inherent assymetry where List is a very general thing. Why does it not make sense to associate them with List? What is characteristic to a List that isn't characteristic to a Positional? Lists can even be lazy so most properties that would follow from a "cached" structure don't even necessarily apply to it.

On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A data type class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES.

The biggest problem with this, as Daniel pointed it out, is that it's not true in the first place. If it were true, it would still be a hassle because we are back to deep analysis of English - a word doesn't always give it away if it's a noun or an adjective and sometimes it can even be both - and during that deep analysis, we might conclude that the does [adjective] terminology is absolutely bonkers. It would make more sense the other way around: is [adjective] and does [noun].

Anyway, I'd say these weaknesses all just show that it's not such a great idea after all to base terminology on peculiarities of a natural language. Indeed, it can very well be a "Larryan" (Larry-ish?) thing - I probably said somewhere that "Larryan" things inflate heavily without his constant assistance to integrate them into a coherent system - obviously it's not possible to just blow the whole terminology away in favor of some simplistic, "boring" terminology; however, let me repeat this once more: it is important to at least recognize and admit when the terminology doesn't help as much as it could/should because we can/have to compensate for it, mostly by documentation but also some finetuning, setting good and advertisable paradigms in code etc.

[librasteve]

I suspect that most languages have Nouns and Adjectives, so English is not unique. I gather that Larry was a linguist and that this class / role dichotomy is deliberately intended to engage our existing language brain structures to help us reason about code.

Since I did not know the "rules" (ok, there are no rules in English), I looked this up:

A noun is a person, place or thing; an adjective modifies or describes the noun. The girl is a beauty -- beauty being a noun. The girl can also be beautiful -- beautiful, in this case, being an adjective. Turning a noun into an adjective requires only a few minor changes to the ending of a word.

The simplest way to turn a noun into an adjective is to add suffixes to the end of the root word. The most common suffixes used to create adjectives are -ly, -able, -al, -ous, -ary, -ful, -ic, -ish, -less, -like and -y. For example, turn the noun "danger" into the adjective "dangerous" by adding the suffix -ous. Other examples include: "The lady enjoys magic; however, she is not very magical herself." "Those who have health are considered healthy, while those who follow fashion are thought of as fashionable." In these instances, the root nouns were turned into adjectives by adding appropriate suffixes.

Sometimes you will have to make slight modifications to the root noun if it ends in -e, -y or -t. For example, if the noun is "offense," the adjective is "offensive." In this case, drop the -e from the noun and add -ive to create the adjective.

source: https://www.theclassroom.com/change-noun-adjective-8387579.html

[2colours]

Indeed - most languages have nouns and adjectives; the question is, why do we need to analyze English words in particular, whether they are nouns or adjectives. It's not regular or even clear enough to be worth it.

[codesections]

@duncand wrote:

A better language design is such that a data type is strictly defined as a set of values, full stop.

If I'm understanding you correctly, this is just structural typing versus nominal typing, right? (With you saying that you prefer structural typing). Imo, both have advantages.

@2colours wrote:

Anyway, I think we can admit that we are typically not linguists, neither Shakespeare

Who is the "we" in that sentence? If "we" refers to "all Rakoons", then yeah, we aren't linguists. If "we" refers to the group deciding on Raku language design then … well, ok, most of us still aren't actually linguists. But I view one of Raku's core selling points as being that it was designed from a linguist-ish perspective (maybe that's part of what you mean with your comments about things being Larry-ish latter on?). And I'd very much like to keep that slant to the language as it continues to grow/evolve – though, as you point out, there's no particular reason to draw more heavily from English linguistic principles than from linguistic principles in other languages.

I personally hope that someone looking back at Raku's overall, collaborative, design decades from now would describe the design team as linguists – and, if the stars align, I'd be thrilled by Shakespeare comparisons … though that's not anything anyone can realistically aspire to, whether writing prose, poetry, or code.

[2colours]

I think we are rallying too far from the original topic of the issue and I have my fair share of responsibility in that, too. Now that the Github Discussions feature is turned on in this repo, maybe we can move the kind of discussions that don't have an explicit tangible goal here.

Besides, I think what I tried to communicate is also falling apart a bit. If we need to stick to the "linguistics aspect": I would advise to think about designing conlangs and what makes a conlang worthy (I didn't want to use the word "useful" because that felt too reductive), and how that can be applied to programming. That seems like a more constructive form of linguistics for our purposes than analyzing one particular existing natural language and map it to programming.

[duncand]

@duncand wrote:

A better language design is such that a data type is strictly defined as a set of values, full stop.

If I'm understanding you correctly, this is just structural typing versus nominal typing, right? (With you saying that you prefer structural typing). Imo, both have advantages.

Actually no, what I'm contrasting here is not structural typing versus nominal typing, that's something else, and in practice a type system tends to be a hybrid of those not just one or the other.

Rather, what I'm arguing for is decoupling of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types. So for example, your routine math operators like add or multiply, or your routine list operators like union or filter, they are not defined as methods of the Integer or List type definitions, but rather are defined in other libraries with different names and they take arguments of type Integer or List etc. Its probably more comparable to how languages considered "not object oriented" are designed, eg how type definitions and functions are separately defined in C.

This is more of an organizational thing for code. The design I argue for still has the interesting features like polymorphism and so on that people often ascribe to OO languages but aren't specific to them.

My point is that having a clear separation between a code unit that defines what a type is, and a code unit that defines operations you can do with types, it can be easier to have consistent naming for things, each of these has their own scheme.

[duncand]

Rather, what I'm arguing for is decoupling of routines from type definitions. ... My point is that having a clear separation between a code unit that defines what a type is, and a code unit that defines operations you can do with types, it can be easier to have consistent naming for things, each of these has their own scheme.

On further reflection, I formally retract my arguments in this thread on good language design, not because I don't believe in them in other contexts, but because I realize that this wouldn't actually solve the problem being discussed on naming roles and classes etc.

[codesections]

Rather, what I'm arguing for is decoupling of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types.

Oh, I understand now; thanks. Well (and you may well know this), in Raku allows for that design as well. Consider the following code:

class Foo {
    method A { say "A method"}
}

my method B(Foo $:) { say "B method"}

my $f = Foo.new;
$f.A;    # OUPUT: «A method»
$f.&B;   # OUTPUT: «B method»

B is a normal method that is "[its] own separate thing that use[s] types" (in this case, Foo). Of course, defining separate methods like that isn't common practice in (most) Raku code, and using it does require the extra & character. But that has more to do with the question of who gets to define the current lexical language: does Foo define it, or does the caller? There are advantages to both, depending on the intent.

[Edit: But, as 2colors noted above, this is probably drifting too far from the issue and this thread likely isn't the best place for this conversation, as interesting as it's been]

[duncand]

Rather, what I'm arguing for is decoupling of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types.

Oh, I understand now; thanks. Well (and you may well know this), in Raku allows for that design as well. Consider the following code:

class Foo {
    method A { say "A method"}
}

my method B(Foo $:) { say "B method"}

my $f = Foo.new;
$f.A;    # OUPUT: «A method»
$f.&B;   # OUTPUT: «B method»

B is a normal method that is "[its] own separate thing that use[s] types" (in this case, Foo). Of course, defining separate methods like that isn't common practice in (most) Raku code, and using it does require the extra & character. But that has more to do with the question of who gets to define the current lexical language: does Foo define it, or does the caller? There are advantages to both, depending on the intent.

To be clear, I was never arguing against using classes to organize methods. Rather I was arguing that methods A and B should be in class Bar rather than class Foo, where Bar is a class with no fields or a static class.

[duncand]

The easiest argument for a routine-type decoupling is to point to any method that involves multiple types as arguments or result types. When multiple types are involved, it is usually a contrivance to say the method "belongs to" one type more than another, by virtue of it living in the class defining the type. Whereas decoupling is then putting all the types on the same footing, and saying none are more special than the rest, and doing this consistently for all methods.

[codesections]

When multiple types are involved, it is usually a contrivance to say the method "belongs to" one type more than another, by virtue of it living in the class defining the type.

This is true in many languages but not in Raku. This took me a while to grasp and I only really got it after reading jnth's answer to a Stack Overflow question asking "Why is adding methods to a type different than adding a sub or an operator in perl6?". The whole answer is worth reading, but the bottom line is what I was getting at before: when a method is defined inside a class, it's part of the class's lexical language; elsewhere, it's part of the caller's.

(Oh and re: your previous point: "a class with no fields or a static class" isn't really a class in any meaningful sense – it's a module/package. Raku supports those, of course, and I'm sympathetic to the claim that they're often a better unit of code organization than the class)