NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/misc/3746

Text File | 1992-11-17 | 3.5 KB | 63 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail] <[e-mail]>
Date: Tue, 17 Nov 1992 22:10:30 GMT
Lines: 51

In article <[e-mail]> [e-mail] (Chris Dollin) writes:
>I've (tried to) direct followups away from comp.arch.

>In article ... [e-mail] (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: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)