parser didn’t get to make its own operators, since everyone can clearly see that it’s still possible, just not for them.
If you look at our brains, one theory that describes how we interact socially is the SCARF model, where the F stands for Fairness. The short version of it is that many of us are built to be triggered when we perceive unfairness, and this is a clear version of an “unfair” restriction, since the core team can utilize it, but the rest of us can’t.
I don’t personally care much about operators, but I think having a limited set of operators that everyone can overload hits the sweet spot. That way you don’t get operator bonanza (where users define arbitrary operators that make code harder to read, which was also the reason the capability was removed), but you still give users the ability to use some common (and useful) operators on their own types.
Why do people not accept that Kernel code can only be written by Elm Makers(Evan) when in JS only makers can make calls to native© code(at least in Browser JS, excluding web assembly)?
I wonder if kernel code wasn’t part of the package that uses it, but centrally defined in the compiler if there were less discussion about how people want it in their packages too? Then it would seem more like a central kernel and less like a privileged package.
I think it’s important to separate a few concerns: I haven’t seen anyone advocate for having kernel code in packages they upload to the official Elm package repository for example. I do think the
It’s also interesting that many languages do have an escape hatch of some sort (Java, Rust, C#, and more), because it is generally something that someone will need at some point. This escape hatch is also present in Elm, but is again only available to the core team. This means there are both those who just consider it unfair to have it locked away, and those who actually need it to complete a task.
The reason the ability to write native code was removed was both because it was never actually intended to be a thing; it was an undocumented “feature” that people started using, but also because it could compromise some of the Elm guarantees, and make it harder for the compiler to transform the generated code. I do think it would have been worth exploring a well defined
Note that I don’t have any personal desire to write native code or custom operators, but I think it’s a fascinating discussion, so I just like participating