“All J verbs (functions and operators) have the same priority and associate right-to-left. For example, a b + c is equivalent to a * (b + c), not (a * b) + c.”*
Your point about not needing operator precedence still stands, though.
You can ignore precedence in the grammar, and then use a pratt parser or shunting yard or something to parse the precedence.
But yes, it does need it, usually. And it's not a huge thing to implement. I usually implement it in the grammar, with inline node folding inserted for left associative operators, which gets me a very nice clean AST.
hyperscript has some operator precedence, but within a given general precedence level you have to explicitly parenthesize if you use different operators:
this eliminates most practical precendence questions
NB: one thing that may strike people as strange is that the parse methods are on the parse elements themselves, I like to localize everything about a parse element in one place
Yes, but it doesn't need any funny parsing trick to handle them. Just parse the whole statement as a list of expressions joined by operators, and then you can convert the flat list into a precedence-respecting tree with a few lines of code and an operator-to-precedence table.
Yes, it's as easy as that. Or check out Jonathan Blow on precedence.
The infamous dragon book convinced people to use the wrong tools and have the wrong mindset. It was a work of incompetence. There were no dragons, but the book itself.
Not if it's s-expression-based! (laughs in smug lisp weenie)
Or, if the programming language uses infix binary operators:
Not if the programming language has evaluation order from left to right, e.g.
2+3*4
is evaluated as
(2+3)*4.
For example J uses this kind of evaluation.
J is APL-inspired, and APL is right-associative, so that would surprise me. https://www.jsoftware.com/help/jforc/preliminaries.htm#_Toc1... agrees with that, saying
“All J verbs (functions and operators) have the same priority and associate right-to-left. For example, a b + c is equivalent to a * (b + c), not (a * b) + c.”*
Your point about not needing operator precedence still stands, though.
> J is APL-inspired, and APL is right-associative, so that would surprise me.
You are indeed right (it has been quite a long time since I experimented with J):
> https://www.jsoftware.com/help/jforc/preliminaries.htm (scroll down to "Order of Evaluation")
Smalltalk also.
You can ignore precedence in the grammar, and then use a pratt parser or shunting yard or something to parse the precedence.
But yes, it does need it, usually. And it's not a huge thing to implement. I usually implement it in the grammar, with inline node folding inserted for left associative operators, which gets me a very nice clean AST.
hyperscript has some operator precedence, but within a given general precedence level you have to explicitly parenthesize if you use different operators:
https://github.com/bigskysoftware/_hyperscript/blob/06f9078a...
https://github.com/bigskysoftware/_hyperscript/blob/06f9078a...
this eliminates most practical precendence questions
NB: one thing that may strike people as strange is that the parse methods are on the parse elements themselves, I like to localize everything about a parse element in one place
Just a single function per level is sufficient for implementing both right and left association. I do not see the problem.
Yes, but it doesn't need any funny parsing trick to handle them. Just parse the whole statement as a list of expressions joined by operators, and then you can convert the flat list into a precedence-respecting tree with a few lines of code and an operator-to-precedence table.
Yes, it's as easy as that. Or check out Jonathan Blow on precedence.
The infamous dragon book convinced people to use the wrong tools and have the wrong mindset. It was a work of incompetence. There were no dragons, but the book itself.