🚀 go-pugleaf

In article <KERS.92Nov17090305@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>I've (tried to) direct followups away from comp.arch.

>In article ... tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>   The problem is that user-defined operators cause problems about which
>   the compiler cannot warn reliably. For the rationale and some examples
>   of what can go wrong, see the ARM, p331.

>It says ``This extension, however, would imply a significant extension of
>complexity of syntax analysis and an uncertain gain in readability.'' It then
>remarks that precedence and associativity must either be fixed for all
>user-defined operators, or a mechanism must be present to define them; it is
>this latter that is the tricky point. (The ``complexity of syntax analysis''
>argument seems to be terribly weak, given that (a) Stroustrup is not stupid,
>and (b) the rest of C++.)

>There are many other things compilers cannot warn about reliably, or indeed, at
>all; writing ``-'' when one meant ``+'', forgetting to increment a counter,
>calling the wrong function (or not calling the right one), writing ``0'' when
>style demands FALSE or NULL_String, and so on. Has anyone done some *research*
>on the issue, rather than making *-informed speculation?

>[My own speculation is that it's all perfectly sensible provided you're
>prepared to forgo the ability to define your own precedence and associativity,
>and that operator tokens are recognisable by spelling just as identifiers are.
>What would be handy, I think, is a way of making *any* dyadic function into an
>infix with a simple syntactic mark, eg, ``E1 @F E2''.]

The precedence problem was actually aggravated by C, and I suspect that it
is necessary to do some pulling back.  The user who has not run into the
specific situation is likely to get a rather large number of the precedences
wrong.  What is the correct association in a << b + c?  Everyone I showed 
this to came up with the same answer; but that answer is wrong in C!  One
cannot even get the compiler to consider spacing in resolving this.  I 
would just as soon go the the APL idea, which only distinguishers unary
and binary.  It would help if we could get a more complicated set of 
parentheses, or allow explicit temporaries to be used to break up the
operation stream; this would certainly be needed if functions produced
a list of results.

I agree that this complexity of syntax analysis is very weak.  Put one
precedence for unary operators and another for binary operators, or even
equate the infix notation x FOO y with !FOO(x,y); those of us who want 
to use user-defined operators would find this a lot preferable to not
allowing them at all, even if we had to use parentheses all the time.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)