🚀 go-pugleaf

I contend that when adding new operators it is much too confusing to allow the
user to choose/define precedence (at least), thoough associativity and
commutativity are less of a problem. The point is that it gets too complicated
for someone trying the READ the program and understand it. Rather, it is
likely better to take the approach of APL and Smalltalk: define one simple
evaluation order and otherwise require parenthesization. In APL I believe
evaluation is right to left; in Smalltalk it is only slightly more
complicated. There are three kinds of operators: unary postfix, binary infix,
and keyword "mixfix". The unary ones are simple identifiers, for example:

	17 negate

The binary ones are formed from a set of "special" characters, and consist of
one or two (maybe even three; I'm doing this from memory) characters from that
set. Examples are:

	x + y
	y << 3

Finally, keyword operators consist of a sequence of one or more identifiers,
each followed by a colon; if there are K identifiers, then there must be K+1
subexpressions, with the pieces of the operators inserted between the
expressions. For example:

	x at: 17
	x at: 17 put: y

The evaluation rule is unary, then binary, then keyword (unless parentheses
further delimit the expression). One DOES get used to this fairly quickly.

Finally, I suggest further discussion of this topic be moved out of comp.arch,
since it is a language/compiler issue, not fundamentally one of computer
architecture.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu