Re: Preferred order of evaluation

Nils M. Holm <fs29@rumpelkammer.uni-mannheim.de> wrote:
>Given a language without any operator precedence, would you prefer
>
>1) evaluation from the left to the right, like a sequence of identical
> Operations in C [a - b + c = (a - b) + c]
>
>or
>
>2) evaluation from the right to the left, like in APL?
> [a - b + c = a - (b + c)]
>
>What are the reasons for your choice?


There is no correct choice, of course. Whatever you pick will have
advantages and disadvantages. That said,


a) Binary operators in APL are right associative.
      I wrote a lot of APL code when I was a kid, and found the precedence
      rules very easy to learn and adjust to. The fact that most of the
      operators I was using were unique to APL meant that there wasn't much
      'interference' from my knowledge of traditional mathematical notation.
      The right associative rule works well for the assignment operator:
      you don't have to parenthesize its right argument.


b) Binary operators in Smalltalk are left associative.
      This means that a string of additions and subtractions:
A + B - C
      or a string of multiplications and divisions:
A * B / C
      will group the same way as they do in traditional mathematics.
      The assignment operator is special, and has lower precedence than
      user-defined binary operators, so you don't have to parenthesize
      its right argument.


c) Binary operators in Self are neither left nor right associative.
      You have to explicitly parenthesize an expression like A + B + C.
      The rationale is that Smalltalk programmers suffer 'interference'
      from their knowledge of traditional mathematical notation, and
      sometimes write A + B * C when they mean A + (B * C).
      In Self, assignment is not a binary operator. I think you write
X: A + B
      to assign (A + B) to X. (I may be misremembering this.)
      With this syntax for assignment, you don't have to parenthesize the
      right argument.


I'm designing a language called Mu which allows you to invent new
binary operators. The assignment operator is called ":=", and is
a binary operator. I started out by picking rule (b). Then I noticed
that I dislike having to parenthesize the right argument to := in
an expression like this:
X := (A + B)
So, I partitioned the binary operators into two sets.
Any binary operator containing the substring ":=" (including "+:=",
"::=", and so on) is right associative, and has lower precedence.
Any other binary operator has higher precedence and is left associative.


I can think of three general design goals that you could use in choosing
operator precedence rules:
i) Keep it simple.
ii) Avoid confusing people who are used to traditional math notation.
iii) Reduce the number of parentheses required to write programs.


I've tried to address all three goals in designing the Mu syntax. The
resulting syntax is reasonably convenient to use, but I'm occasionally
annoyed that the precedence rules are not closer to conventional
mathematical notation. However, I have strong reasons for wanting a
simple, context-free grammar (no operator precedence declarations), so
I'm prepared to live with the current compromise.


At some point, when a larger body of Mu code exists, I plan to write a
program which analyzes a body of Mu source code, and computes a set of
operator precedence rules which would minimize the number of
parentheses that you would have to type. I've often thought that, if
this had been done for the C language early in its design, that the C
operator precedence rules would be more convenient to use than they
currently are.


Doug Moen -- dmoen@mks.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.