🚀 go-pugleaf

In article <2428@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>This is true.  I would be willing to give up a heck of a lot on precedence
>structure, however.  The precedences, except for the common arithmetic
>operators, are fairly arbitrary, anyhow.  Why not allow the parser to
>ask the programmer for the preference order, as well as evaluation order
>if it makes a difference?  A lot can be helped by allowing explicitly
>temporary variables to handle intermediate results.
>
>There are ways around the problem of precedence.  Maybe we should get rid
>of it completely, like APL.  There are parentheses.  The compliler can
>ask the programmer these facts.

As you say, precedence is unnecessary.  Parentheses are sufficient.
Application-oriented notations, such as the use of infix numerical
operators with standard mathematical precedence, can be an add-on
feature, operative within delimited textual regions (e.g., on the
Symbolics workstation, any program text surrounded by sharp-lozenge
and lozenge characters).  One can define a notation to one's own
liking in the same way.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.