Order of precedence

Joachim Durchholz joachim.durchholz at munich.netsurf.de
Wed Jan 27 19:40:23 UTC 1999


Eliot & Linda Miranda wrote:
> 
> So we're supposed to do without #==, #~~, #->, #@? 

Of course not. A system that doesn't allow the definition of new
operators (as shortcuts for the *very* common operations) isn't going to
be very useful, so this is just a straw argument.

> And where does mathematics define commonly taught and understood
> precedence rules which include the relational operators?

Relational operators generally have a lower precedence than arithmetic.
This is because these aren't considered operators in general math, but
delimiters in equations (resp. inquations).

> What are the relative recidences of + - * / \\ // < <= > >= = ~= ?

>From my above remarks, a highest-to-lowest precedence table is actually
easy to construct, and actually observed in multi-precedence languages
like C and Prolog:

Exponentiation  ^ (is this actually in Smalltalk?)
Multiplicative  * / // \\
Relational      < <= > >=
Equality        = == ~ ~~
Assignment      :=

Exponentiation should be right-associative (following mathematical
tradition), all others are left-associative.
The separation of relational and equality operators on different
precedence levels is actually not mathematical tradition, but
programming tradition (since Algol 60 I think).

> What's the scheme for defining the precedence of new operators a
> programmer might introduce?

There are two sensible positions: between Equality and Assignment (so
that they are always evaluated last), or between Multiplicative and
Equality (so you can compare results from user-defined operators).
One could also consider them to be highest priority, but I don't feel
one should do that (it's just an intuition, I couldn't list reasons,
except that I don't know of any language that makes them
highest-priority).

> How can one ensure that different programmers use the same precedence
> order if they both introduce a new operator?

Operators from different authors cannot really combine (and usually
don't anyway), so it isn't too harsh to declare them non-associative.
This means that the parser insists on parentheses to disambiguate
expressions like 2 @ 3 @ 4, or 2 -> 3 @ 4.

> Or is maintaining readability less important than attempting to
> provide an inaccurate simulation of mathematical notation (e.g. *
> instead of adjacency)?

Bah. No rethorics please. I understand you are accustomed to Smalltalk
tradition and don't want to learn new tricks for little gain, but that
doesn't necessarily mean that the position of anybody with a different
opinion is so ridiculous as you present it here.

> I don't accept the argument that its good pedagogics to maintain an
> inaccurate and partial simulation of common mathematical notation.  I
> do accept the argument that its good pedagogics to use simple but
> adequately powerful rules.

There is no such thing as "mathematical notation" anyway. The notation
varies wildly across branches of mathematics.
However, pedagogically, there is no point to pretend there are no
precedence rules. There are.
When I learned Smalltalk, I had some (admittedly minor) difficulties to
adjust to the no-precedence rule.

> I think very strongly that the current design of the infix rules is
> better than any other programming language I've used, that its easier
> to teach, that its easier to learn, and easier to use.

I think that's entirely subjective. I'd go so far to agree that your
point of view is reasonable, but I hope you can agree that mine is
reasonable as well.

However, I think the real reason for not having precedence rules in
Smalltalk isn't "quality" (in whatever sense), teachability, ease of
learing, or ease of use. It is just that precedence rules would double
the amount of syntax rules for Smalltalk. In a more conventional
language, precedence is a negligible part of the total syntax and the
Right Thing to have; in Smalltalk, it would just take up a
nonproportional amount of attention, so it is reasonable to not have it.

Regards,
Joachim
-- 
Please don't send unsolicited ads.





More information about the Squeak-dev mailing list