🚀 go-pugleaf

In article <Bw8ADK.144@news.orst.edu> myersn@hobo.ECE.ORST.EDU (Nathan Myers) writes:

> I have long ignored "exponentiation proposal" notes, but it seems
> time to point out that there is no operator~(T,T) defined yet.
> Simply allowing it to be defined would permit experimentation,
> without committing anybody to a bigger language if the use didn't
> "catch on".

Binary operator~ is certainly one possibility for exponentiation.
operator*^ and operator^^ are other possibilities; of the three, I
think that *^ is the best.

Regardless of the name, however, I feel strongly that a real
exponentiation operator is far better than an operator which can be
defined as exponentiation by the user.  First, a compiler is much more
likely to optimize exponentiation aggressively if it is built into the
language than if it's something the user tacks on.  (Depending on
exactly what is inline and in scope, it might not even be possible to
do certain optimizations with a user-defined operator.)  

Second, if users each define this operator for themselves, then each
programmer will almost certainly define it slightly differently.  This
is likely to cause subtle bugs and conflicts when the work of
different programmers is put together.

Finally, and most important: things like exponentiation simply belong
either in the language or in the library; users should not be forced
to write them for themselves, any more than users should be forced to
implement malloc() or sin() or qsort().  Defining commonly used
operations and functions is what languages and libraries are for.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!