robin <[log in to unmask]> wrote:
...
>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.

Congratulations.  But the fact _you_ haven't had the problem doesn't
mean that it isn't.  It's a _reasonably_ good design.  The error really
_is_ considerably less common than many others.  That's not a
reason to ignore it though.  The discussion is valid.  Many of your
arguments against changing have not been.

The only real trade-off is how much benefit there is vs. how much
trouble it is to change.  It would be considerable trouble to change.
It would be a small (but positive) benefit.  I don't think it's worth it.
But, that doesn't mean that I'd use the same design on a totally
_new_ language.

...
>> >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?

Your question is a non-sequitur.   It makes no sense in this
context.  If you type an & when you intended to type an
exponentiation operator (whatever you use for that), then
the character will be followed by whatever you intended as
the second operand to the exponentiation operator.  That's
a detectable violation of the syntax rules of the language.

I repeat: if you're going to try counter-examples, you might at
least strive for valid ones.

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

Now you're getting to real counterexamples.  However, omitting
one * in the existing operator almost always leaves valid code.
That's the kind of thing that initiated the discussion about "common
errors" that could be reduced.  A kind of typographical error
which almost always leaves an unintended but valid result is worse
than a similar possible typographical error which only sometimes
leaves an unintended but valid result.

Hitting other keys adjacent to the ^ might also leave a valid,
unintended result:  a^b might be aTb or aYb and you might
have these as declared identifiers (or you might be coding
using implicit declaration).  On the other hand, similar problems
exist with the ** operator: aIIb, aUUb, etc..

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

Some equipment does NOT have %, &, !, <, >, ", ', etc..
It's a pretty certain bet that most equipment manufactured
in western Europe and the Americas in the last 30 years
*does* have all of those, including the ^.   The character
may, by default, be eliminated by an internal hardware
switch, and the code mapped to something else if the
hardware was sent to some markets.

But, that was ISO 646, and was 30 years ago.  The world
has moved on.  Nowdays, the only real problem with ^ is
that some people have to type more than one keystroke to
get it.  (I do.  If I type ^ followed by e, I get ê.  To get  ^e,
I have to type ^ followed by a space followed by e.)
Anyway, you're arguing in favor of a two-keystroke form
too (for everyone, not just for some).

At least this is another time you have indeed stated a valid
objection.  Yes, the increased difficulty some people
would have in using ^ is part of the "considerable
trouble to change" that I mentioned above.  But it isn't
by itself a compelling argument.  The following characters
often have the same difficulty: ', ", ~, and `.  Two of these
_are_ used by the language.  A lot of my strings inadvertently
begin ä... rather than "a....  Fortunately that's also a detectable
error.


...
>> >In any case, the argment is specious.  Try replacing
>> >"*" and "^" in your argument with "+" and "-"
>> >(these keys are adjacent).

As I've  said before, the fact that the language will
still contain possible examples of simple transpositions,
omissions, and inclusions that leave valid, but unintended
code, does not necessarily mean that fixing one such
instance is a useless objective.  These examples are
therefore irrelevant to the question of the exponentiation
operator.  They _might_ be considered valid in any discussion
about an alternative selection for the + and - operators. ;-)

>There's no substitute for checking.

There sure isn't.  But, people make mistakes.  The ones
that are the worst are the ones that they thought they _did_
check, so they don't subsequently.  People get distracted,
tired, or in a hurry.  Later, when a problem arises, they
no longer remember the circumstances that existed when
the code was written.  Nor do they usually have time
to reread and verify _every_ line of code.  They concentrate
their debugging effort in those places they think the error
most likely - which often isn't where the error really is.
Sorry, but that's how things really happen, even with
experienced and capable programmers.

One object of language design should be to minimize the
likelihood of common mistakes going unnoticed by the
compiler.  Language design is almost entirely a balancing
act of sometimes not altogether compatible objectives.


...
>> 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!

That's what I've been saying repeatedly.  It's one of the
reasons that I'm surprised by the peculiar nature of your
vehement responses.  With respect to the basic issue
of the discussion, I've always been in full agreement with
you.


In any case, the present syntax has its problems, but works
well enough that changing it would cause more problems
than it would fix.  That has consistently been my position.

The problem is that you're giving ammunition to those
people who support such a change.  By circulating your
easily demolished "reasons" for not changing the operator,
they can claim that there aren't any valid ones.

--
J. Giles




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