Parsing R code: Freedom of expression is not always a good idea (2012)

Re:Parsing R code: Freedom of expression is not always a goo... by hoosieree on Tuesday June 14, 2022 @10:26AM (#31740009)

APL grammar has its flaws, but one thing it gets really _right_ is operator precedence. In an expression like this:

    A op B op C op D

No matter what _op_ is, it parses right-to-left:

    A op (B op (C op D))

Much nicer than having to learn a subtly-different version of C's already convoluted operator precedence[0] with each new language that comes out.

[0]: https://en.cppreference.com/w/c/language/operator_precedence

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by mst on Tuesday June 14, 2022 @11:06AM (#31740587)

I genuinely really like it - strict left-to-right or strict right-to-left are so much more predictable at least for arithmetical type expressions (I might still prefer specific precedences for =/==/etc.).

However at this point something PEMDAS-like seems to be substantially easier to understand for most people since it's AFAICT the common rule taught in (high school) mathematics these days.

Trade-offs all the way down, as ever.

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by yakubin on Tuesday June 14, 2022 @12:36PM (#31741952)

I've just started reading about APL, so maybe I'm wrong, but I think there is one caveat: you need to know which operators are monadic, and which are dyadic, because if op is monadic, then it may be:

  A (op (B (op (C (op D)))))

[ Parent | on HN ]