> From:          "James Giles" <[log in to unmask]>
> Date:          Thu, 17 Aug 2000 19:53:58 -0600

> robin <[log in to unmask]> wrote:
> ...
> >> Some people, when trying to write a**b accidentally write a*b
> >> instead.
> >
> >It's something that's blatantly obvious.
> >Try looking down the barrel of a rifle and of a
> >double-barrelled-shotgun. Spot the difference?
> 
> Yeah, but they're both still guns.  Same with * vs. **, both are
> still operators.  Both are still legal in the code.  If I'm reading
> old code, or code written by another programmer, I have to stop and
> double check the intent.  Many users simply assume that they'd never
> get something so simple wrong (and, hence, don't read it that
> carefully).

> It has been my observation that a significant fraction of errors
> people take long intervals of time to resolve are trivial in nature
> (just exactly this kind of error).

In 30 years I've never come across this (mis-typing **) as a problem.
By way of contrast, mis-spelled variable names, O instead of 0, 1 and
I etc etc, and going beyond column 72, starting in column 6 and so on
have been the principal sources of typographical errors.

>  It takes them long to reslove
> because they look for programming errors (using the wrong
> algorithm, etc.) not syntax errors.  It's their fault, but can
> sometimes be limited by more careful language design.
> 
> >>  If your intent is to reach for the ^ key, this kind of
> >> accidental fault is almost impossible (there's no nearby key that
> >> would be valid instead,
> >
> >There is -- it's the "&" key right next door.
> >The "&" key terminates the line (or starts it if it's first).
> 
> And is illegal if it has additional non-comment non-blank text after
> it.

And if it doesn't?

> Hence x&y would be caught by the compiler.  On the other hand x%y
> _might_ be legal and valid - not really probable, but maybe.  (If
> you're going to try counter-examples, you might at least strive for
> valid ones.)
> 
> >> and omitting or typing more than
> >> one ^ would be detectable).

Omitting one ^ might not be detectable, if the result is a valid 
name, for example.

> >>  It's not a common fault.  It's
> >> not a particularly strong argument against **.  The fact that ^
> >> is more mnemonic is more compelling.

Not really.

> >Not all equipment has a "^" key.
> 
> All web browsing hardware/software should be able to 
> handle the '^' character (by international standard).

Web-browsing hardware has nothing to do with the issue.
Some equipment does NOT have "^".

> It's a character
> that's allowed to vary by the ISO 646 standard, but that's mostly
> now regarded as obsolescent.  In any case, I'm not advocating
> changing Fortran's operator.  I merely comment that ^ is more
> mnemonic.
See above. 
> >In any case, the argment is specious.  Try replacing
> >"*" and "^" in your argument with "+" and "-"
> >(these keys are adjacent).
> 
> But with different shift states.

That's irrelevant.  a-(b*c - e/f) can easily turn into a+(...
because you need the shift key for "(".  Same goes for
(a*b -c/d)+3; the "+3" can go to "-3".

There's no substitute for checking.

>  In any case, as I clearly
> said before, the possibility of error is not a particularly
> compelling reason to change the operators around.  All languages
> have the possibility of subtle, single character errors that result
> in still legal code with different semantics.  These are all
> instances of such cases in Fortran.
> 
> (However, the claim the the argument is specious is simply wrong.

Most people would agree that it's specious.

> The fact that other, similar problems might exist doesn't mean it's
> useless to try to solve a particular one.

It's not one that needs "solving".  If it works, don't fix it!

>  You might as well argue
> that it's useless to try to feed starving Africans because there
> are, in any case, still starving Asians .)

That's got nothing to do with the price of fish.

> >There's no substitute for careful checking of what has been
> >typed -- even the humble expression.
> 
> True.  But that wasn't the issue being discussed.

But **is** the issue.  The issue is about typographical errors.
You should look at the * and ** issue in wider context and to 
recognize it as part and parcel of preparing correct programs.

> J. Giles


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%