15 Sep 1996 00:40:31 -0400

Related articles |
---|

Preferred order of evaluation fs29@rumpelkammer.uni-mannheim.de (Nils M. Holm) (1996-09-05) |

Re: Preferred order of evaluation leichter@smarts.com (Jerry Leichter) (1996-09-06) |

Re: Preferred order of evaluation dlmoore@ix.netcom.com (David L Moore) (1996-09-07) |

Re: Preferred order of evaluation ok@cs.rmit.edu.au (1996-09-15) |

Re: Preferred order of evaluation dmoen@mks.com (1996-09-15) |

Re: Preferred order of evaluation gbcacm@ccs.neu.edu (1996-09-15) |

From: | dmoen@mks.com (Doug Moen) |

Newsgroups: | comp.compilers |

Date: | 15 Sep 1996 00:40:31 -0400 |

Organization: | Mortice Kern Systems, Inc., Waterloo, Ontario, Canada |

References: | 96-09-021 |

Keywords: | design |

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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.