Re: Operators -> unit analysis

[Tucker Taft <stt@averstar.com>]

Ted Dennison wrote:
> 
> In article <8531v6$6qk$1@nntp3.atl.mindspring.net>,
>   tsikes@netcom.com (Terry Sikes) wrote:
> > In article <850tl9$thu$1@nnrp1.deja.com>,
> > Was this point argued at length after the decision was made to add the
> > various annexes?  I'd think that this would be better received if it
> > was tied to the Numerics annex, since certainly this would be the
> > major area of use.
> 
> Not by far. There are many applications in many realms of study that
> have traditionally been described by some kind of mathematical notation.
> The Gnat Snobol packages are a very good example for pattern matching.
> Possible other applications off the top of my head are: strings, lists,
> sets, database queries, BNF, Music.

For what it is worth, in my view adding lots of operators
is not doing the user any big favor.  Good old function-call syntax,
using named parameters when appropriate, is the clearest for most things.  

The advantage of operators is when a single statement involves many 
operations, and the use of infix operators makes it much easier to "grok"
what is going on.  That advantage disappears quickly if you end
up with unfamiliar operators interspersed within the complex
expression.  Even "familiar" operators are bad news if used
in unfamiliar ways. 

Furthermore, in many of the cases you mention above, you 
don't really want the operators *executed*
at run-time.  Instead, you want to create some kind of tree
representation, and then interpret it in some special way.
Building these trees at run-time seems like an inefficient way
to do things, which means the contexts where they will be useful
is even more limited.

In my view, operators are great for complex number packages, 
and other numeric-like things (matrices, vectors, bignums, etc.),
but as soon as the meanings of the operators becomes even slightly
obscure or non-standard, the value to the reader drops precipitously.
 
> --
> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA