🚀 go-pugleaf

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''.]
--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods