Wow, this is (evil) genius.
It suggests all sorts of obnoxious "features" for esolangs:
- Order of operations depends on number of terms in more complicated manner.
- Order of operations depends on data? This would make compiling the language basically impossible, but you could probably get away with it in an interpreter.
- Parenthesis have side effects, in addition to changing order of operations.
> Order of operations depends on data? This would make compiling the language basically impossible, but you could probably get away with it in an interpreter.
This is not even a hypothetical feature. There is at least one language which used a type information to resolve associativity [1]. I have even used one, it works, but was very hard to get accustomed for me.
Very interesting. And it's not even an esolang, but something actually intended for production use!
Looking closer, it's not as bad as what I had in mind. Association order only depends on type, not value (which is what I meant by data). This means you can figure it out at compile time, and actually makes some sense if you want to be able to use standard mathematical notation like they do, which has operators with different association orders.
That reminds me of the Husk golfing language [0] that I played with a few years ago. Each character corresponds to a few different commands, each with a distinct list of argument types.
The interpreter takes a brute-force approach of going through each interpretation until it finds one that works. Sometimes, it simply hangs forever, and other times, it interprets the program differently than you'd expect. But I always considered that as part of the charm of golfing in it.
