Operators as syntax sugar

Operators are easy if you already know their meaning. I would argue that most people learn the basic operators for mathematics (+, -, /, *) and tend to find their presence in programming languages unsurprising. In fact, I believe most people would find it an unecessary burden to learn how to do maths in a way that doesn't correlate to the same syntax they learned in school. In other words, I believe many would consider Gren a worse language for not having operators.

On the other hand, operators are hard if you have no idea what they mean. Most people prefer actual functions with actual names, than to read cryptic symbols with different precedense rules and inline semantics. With very few exceptions, I believe operators can make code easier to read, at the expense at making code harder to understand.

One problem with Gren's current operators, is their lack of flexibility. If someone was to create a BigNumber type, it would be impossible to use it with +, even though it would make sense to use the same DSL with a BigNumber.

So, here is what I propose:

Any operator which isn't already well known or can greatly enhance the readability of Gren code, should be removed.

The operators that remain, will become syntax sugar. This means that it will no longer be possible to define operators in Gren code, even when limited to core API's.

The mathmatical operators will desugar to regular function calls:

• + => plus
• - => minus
• / => divide
• * => multiply

The implementation used, depends on the functions in scope. Since Gren plans to remove default imports, and replace type classes with parametric modules, this will give users the ability use these operators with custom types. Future Int and Float modules will implement the above functions.

There are more aliases:

• == => equals
• != => notEqual
• ++ => append
• |> => applyRight
• <| => applyLeft
• < => lessThan
• <= => lessThanOrEqual
• > => greaterThan
• >= => greaterThanOrEqual

The boolean operators && and || will remain builtins, due to their short-circuiting mechanics.

Operators not mentioned above will be removed.

Using operators as function references (map (+) [1, 2, 3]) will be a compile error. Use the named function reference instead.

No files, tests, or compiler entry points are named. Start by tracing how Gren parses and lowers operators, then review the existing operator definitions and related tests; done would require an agreed operator set, desugaring behavior, and handling for operator references.