5 ms·
You know --- more and more --- I kinda like the REBOL approach --- forget precedence. Rather, just go L to R except where superceded by parens. Explicit and ea
by sreekotay 6y ago
You know --- more and more --- I kinda like the REBOL approach --- forget precedence.
Rather, just go L to R except where superceded by parens. Explicit and easy to understand.
(Though I say that not having lived it in production, lol - so take with a grain of salt)
Over time, readability/grokability tends to trump other factors...
- ChrisSD 6y agoThat kind of thinking inevitably leads to S-expressions.
- zokier 6y agoOr RPN
- sreekotay 6y agoMaybe - REBOL was interesting in the functions are all RL to precedence and operators are all LR precedence. It's clean(-ish) without being too verbose/messy. It's not perfect - just thought it was an interesting direction to ponder...
- sreekotay 6y agoYou might be right about that. Maybe we need more bracket flexibility or something. Or something built for TOOLING - nobody just writes freeform anymore?
- jcranmer 6y agoBecause parsing "a += b * c" as "(a += b) * c" is a wonderful, intuitive program. (This does assume that op= is an expression in your language.)
- phkahler 6y agoIncluding precedence rules will take care of that.
- masklinn 6y agoThat… would be jcranmer's point, they're replying to a toplevel comment advocating for not having precedence.
- sreekotay 6y agoEdit: Realized what I was tring to say: Intuitive might be the wrong thing to chase. Intuitive to who? :) Trivial programs are trivial. We might be stuck in the BCPL derived syntax that trade a false notion of intuitive for complexity of implentation and maintenance. (And I do mean might --- it's not hard not to think incrementally from the languages we know) --- but "inituitive" is EXACTLY the problem: I guess I was arguing we might consider searching for simple and predictable (even if that comes at the cost of slightly higher initial learning?)
- sreekotay 6y agoe.g. maybe write it as "b * c += a" ? ... lol full on LR - no ambiguiity.
- tlb 6y agoSmalltalk too. I really liked it. In practice, C compilers warn you if you try to take advantage of && having higher precedence than ||, so other than a few very simple rules wise programmers use extra parens anyway.
- mamcx 6y agoI suspect is not that bad to force to group things manually (1 + (....)) but is truly precedence the biggest issue? I think even without that hand-coded parsers are still superior for error reporting and other factors?
- jraph 6y agoI just wrote a parser in TypeScript that parses itself (for fun, and not quite done yet). Precedence and associativity is a painful aspect of parsing JavaScript… and probably C, Java and many programming languages that look like C. It took me a non negligible part of the time to think about how to handle this. With the presence of infix, suffix and prefix operators, and weird operators like new…(), ? … : …, and a lot of rules and exceptions, it's a lot of fun (for instance, yield is an operator in JavaScript. It takes an optional expression. However, 1 + yield is forbidden…). The grammar of JavaScript expressions is… not simple. And then, you have Automatic Semicolon Insertion, which forces you to backtrack and snapshot / restore the lexer state when consuming white characters EVERYWHERE (well, not literally everywhere, but still) because things may behave differently if there is a new line. And of course, new lines cannot happen in some constructs (there are a few exceptions to the general behavior of ASI), so you need to take care of this too. And then you have the comma operator that is allowed in some places taking an expression (especially in older constructs, and disallowed in other places (especially in newer constructs). So you need to handle this too. Parsing the rest is easy. It's just that there are a lot of things in the language so it's a bit long to write.
- deleted 6y ago[deleted]
- dTal 6y agoThe APL approach, which is mostly just simple RL-associative + grouping parentheses, works surprisingly well in practice - although that probably owes something to the simplicity of the syntax and the way idiomatic APL uses mainly the built-in 1- and 2-argument functions.
- sreekotay 6y agoThat was the thought: is there some non-BCPL like grammar that makes sense. Like... (not fully formed thought here) JSON is easy but verbose - YAML is nightmare by cleaner. Maybe we're looking at it wrong....
- dTal 6y agoAs a nearby comment observes, this leads to s-expressions. The connection between APL syntax and s-expressions is surprisingly close. Start with prefix notation and right-associativity, add grouping parens, and you have something that looks like lisp. The Nial language is an outright fusion of the two that's fun and enlightening to play with. https://en.wikipedia.org/wiki/Nial https://en.wikipedia.org/wiki/Nial https://github.com/danlm/QNial7 https://github.com/danlm/QNial7
- hinkley 6y agoThe standing rule has always been 5th grade math comprehension. As with most things, switching from too much to none is generally not an improvement. Perhaps languages should have 8 levels of precedence instead of 18.