🚀 go-pugleaf

In article <INFO-M2%90072615091342@UCF1VM.BITNET> Modula2 List <INFO-M2%UCF1VM.BITNET@jade.berkeley.edu> writes:
>On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said:

>>*I* certainly don't want to maintain programs that redefine
>>precedence of existing operators.  The other features sound
>
>You have a good point there.  The reason I included existing
>operators was to prevent 'wrapping' and allow such things as the
>definition of a CARDINAL (operator) INTEGER operation
>(for convenience).  I think that defining the precedence of operators
>is a good compliment to op overloading.  I could live without
>redefining the existing operators.

The approach used by Clu (or at least explain in the reference manual)
is pretty cool.  They define many operators and their precedence
and associativity (I don't know about commutivity).  I believe these
properties are fixed, as is the set of operators.  Therefore, you
and I and the parser can look at the program and all parse it
identically.

However, things get more interesting.  "x + y" is transformed into
the function invocation "sometype$plus(x, y)" where sometype is the
type of x and $ is the selection symbol.

This happens with all the operators, including "." and "[ ... ]".
So it's fairly easy to define something like "+" as string concatenation.
You add a function "plus" to the cluster defining strings and
the parser will fix you up.

I should apologize to Clu hackers for mangling the explanation of
their language!

My other arguments related to difficulties in defining the language.
I still hold that it's a tough job.  It's quite difficult to get a set
of features to work together well.  I can pick nits over lots of
unimportant things, but getting the big picture right is probably
harder than implementation.

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu