🚀 go-pugleaf

>How frequent is a**p anyway? (has anyone got any data?) How confusing
>would it really be? Many people use spaces to clarify (to their eyes,
>if not to everyone else's) code, e.g. a * *p. Also, not all overloading
>creates confusion, especially when identifier names are chosen with
>a minimum of care (want would x**e mean? a**xptr mean?). I doubt the
>case is clear cut.

About the most frequent operation in digital signal processing is some
form of the dot product.  Consider

double dotProduct(double *x, double *y, int n) {
	double sum = 0.0;
	while (--n >= 0) sum += *x++ * *y++;
	return sum;
}

I guarantee (as someone who's written a large amount of numerical C
and C++ code) that there is a great deal of code of the above type,
and while I'm generally careful to space it as above, I've seen code
that doesn't have this spacing.

You'd break programs, no ifs, ands, or buts about it.  It's true that
this breakage would be detected at compile time (the right argument to
'**' would be a pointer).

As Dr. Stroustrup suggested, an alternative would be to have '*' '*'
mean exponentiation and handle x '*' '*' ptr as a special case, so
it would keep its meaning of dereference-and-multiply.  That would
work, as best I can tell, for C, but in C++, '*' might be overloaded
for the unary or binary case.  This hack wouldn't work then or would
cause nasty surprises.

I think Matt Austern's analysis is basically correct: the exponentiation
operator should be a token, one not appearing in the language currently
so that it cannot break existing programs.  Those in favor of ** must
show, IMHO, that it would break virtually no programs, and this can't
be done without introducing a series of hacks.  If every other language
used **, this would be a strong argument in its favor, but many languages
use ^ instead.

Furthermore, there are three other considerations: the ability to construct
the corresponding assignment operator (eliminating !), the
internationalization issues (eliminating several characters like @ that
aren't on all keyboards), and avoiding breaking analogies between
operators (there is a relation between & and &&, and | and ||, which
should not be violated for ^ and ^^).

>I am not arguing that ** is THE right solution, but that given the
>demand for it and the lack of ginuinely nice alternatives ** should
>not be written off without a thought and/or in the belief that it
>is technically infeasible to provide it.

Before Fortran, no one thought ** should mean exponentiation.  Any
reasonable token choice that doesn't violate one of the above
considerations will work.  Austern's *^ is as good as any.



--
Joe Buck	jbuck@ohm.berkeley.edu