search

haasn / -g-pl

/g/ programming language
13 stars 2 forks source link

Infix Operators vs Functions #9

Open haasn opened 13 years ago

haasn commented 13 years ago

Should we implement an operator table (eg. fixivity and associativity), or should we just leave everything as functions?

The advantage of functions: Very easy to implement, very easy to parse with existing rules The advantage of operators: Easier to understand for non-lispers and newcomers

Functions could look like:

>mfw >mul 3 >add 2 5

Infix could look like:

>mfw 3 * (2 + 5)
haasn commented 13 years ago

I just thought about it, and our existing “x is y” expression is itself already an operator.

So either we have to change this to “>is x y”, or we add parentheses, grouping, operators, precedence and associativity rules.

This issue still remains to be resolved, what are your votes? My vote is for keeping the functional style and using “>is x y”, ”>add x y” and so forth.

yate commented 13 years ago

grouping, precedence, and associativity should take care of themselves if we write the parser and define the language correctly. Then again functional style may work better as part of the esoteric feel.

haasn commented 13 years ago

Further comments on this? Graydude?

This is one of the road blocks we should work on resolving immediately so we can further development of the language. Once this and looping is in, I will probably start working on my implementation.

yate commented 13 years ago

are we all working on different implementations?

haasn commented 13 years ago

Yes, at least I intend to work on my own implementation (which will be an interpreter).

haasn commented 13 years ago

I'm closing this. If we ever decide to change it, re-open. But I think the functional style fits the esoteric feel well.

haasn commented 13 years ago

I'm re-opening this since I developed an algorithm with which to implement infix operators using a monadic parser. (supports all associativity / precedence rules and parentheses)

As such, it may yet be a possible option. I'd have to restructure the Expression parser to be usable recursively though, which can solve some issues but also cause some. I'll experiment with it.