 |
 |
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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%