🚀 go-pugleaf

In article <BEVAN.92Aug31101447@tiger.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <BttB9z.IAy@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

			...................

>   Also, mathematicians especially use lots of operators.

>They also use lots of Greek letters (at least in the sort of maths I
>read).  It is reasonably easy to replace them with something else, and
>IMHO you can do the same thing with the operators.  Of course I expect
>that most mathematicians lament the loss of Greek characters when
>writing programs, so I don't expect them to give up operators.

This is totally different.  The name of a variable is purely arbitrary,
and any other string of symbols recognized as one is just as good.  But
an operator is a constant, and cannot just be renamed.

Now one can attempt to define an operator in terms of "system primitives,"
but this cannot always be done reasonably, and an attempt to do so may be
highly machine dependent.  Try defining the Boolean operators or shift
operators in terms of the other operators.  It is somewhat easier to
define a test for overflow in terms of the others.  In all of these
cases, the resulting code would be obviously inefficient.

>   Despite what the CS gurus say, allowing the introduction of
>   additional functions is not the same thing.

>Semantically it is, and that is what really counts.
>Some languages do allow you to define infix operators (Haskell and ML),
>but there are very few that allow you to define distfix syntax.
>Of those that do they are either quite old or designed for completely
>different purposes than numerical work.  Also a problem with distix is
>that it is very easy to get ambiguities and unless you are going to
>introduce some user defined precedence (which I'm not even sure would
>solve the problem), the only solution is to put parentheses around
>phrases.  Once you do this, you might as well be using a prefix or
>posfix only language.

I believe that most mathematicians would not worry too much about the
need to put parentheses, although they would probably want a more efficient
way of doing it, and definitely one easier to read.  Counting parentheses
is slow and fraught with error.  But the precedence among the operators in
the HLLs is quite arbitrary, and except for the "standard" arithmetic
operators, and the general, but not universal, rule that unary is done
first, is likely to be messed up.  I suggest the language people come up
with better ways to handle parentheses and at least greatly reduce the
application of precedence rules.  

>   Also, mathematicians and scientists are accustomed to using
>   whatever syntax they like, as long as it does not lead to confusion.

>Confusion for whom?  I get very confused when I read books that use
>|A| to mean three different things depending on the context (which
>isn't always immediately obvious).  With all due respect to
>mathematicians and scientists, just because they are accustomed to
>creating syntax on the fly, it doesn't meant that they are any good at
>it (where "good" is totally subjective, but I'll take it to mean that
>other people find it readable and better (another subjective term)
>than anything else).  For example, I'm sure Frege thought he had a
>great notation for his logical formulae, but IMHO (and with plenty of
>hindsight :-) it was needlessly complicated. 

Do we not have overloaded operators now?  The operations of + - *
are defined for various types, and in common mathematical use they
extent to many other types, such as vector and matrix.  In some cases
the extension is even non-unique; is A*B, for A and B matrices, is it
the element-by-element product, or the matrix product?  I have used both.

And when mathematicians do not like notation, they change it.  There are
no committees to go through, and in the meantime, communication is not
so badly affected.   Sometimes, even if it is bad, it is not considered
worth changing.

The CS people should not be telling users that the hardware/software
combination is "smart."  Rather, they should emphasize that it is very
unintelligent, but very fast--a super-fast sub-imbecile.  They do only
what they are told, no matter how stupid.  For a computer, there would
have to be very careful translations.  These could be local or global;
the .h files are such, and are in common use now.  But they, and the
current methods of incorporating user-defined macros, are inadequate.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)