Related articles |
---|
[20 earlier articles] |
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-18) |
Re: language design tradeoffs e86jh@efd.lth.se (1992-09-19) |
Re: language design tradeoffs maniattb@cs.rpi.edu (1992-09-19) |
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-20) |
Re: language design tradeoffs eifrig@beanworld.cs.jhu.edu (1992-09-19) |
Re: language design tradeoffs maxtal@extro.ucc.su.OZ.AU (1992-09-21) |
Re: language design tradeoffs jch@rdg.dec.com (1992-09-21) |
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-21) |
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-21) |
Re: language design tradeoffs raveling@Unify.com (1992-09-21) |
Re: language design tradeoffs alvin@eyepoint.com (1992-09-22) |
Re: language design tradeoffs kcoppes@aardvark.den.mmc.com (1992-09-22) |
Re: language design tradeoffs dmason@plg.uwaterloo.ca (1992-09-22) |
[8 later articles] |
Newsgroups: | comp.compilers,comp.human-factors |
From: | jch@rdg.dec.com (John Haxby) |
Organization: | Digital Equipment Corporation |
Date: | Mon, 21 Sep 1992 10:00:36 GMT |
References: | 92-09-048 92-09-123 |
Keywords: | parse, design, algol68 |
[Digression, on the subject of type-safe operator over-loading:
Take a look at Algol 68].
There seem to be two approaches to language design being talked about
here: that for the habitual programmer and that for the new (or at least
relatively inexperienced) programmer, although there is considerable
blurring between the two.
Semi-colons are a point where the two camps seem to have most antagonism:
on the one hand, not understanding where the damn things are needed is a
problem for new programmers, but experienced programmers like them
because, once you have a semi-colon reflex, they provide better error
recovery. Personally, I don't subscribe to this point of view.
I firmly believe, having written in a variety of languages and fixed a
variety of bugs that run-time errors caused by the the presence or
omission of a small syntactic mark (eg semi-colon) can be avoided by
careful design of the programming language so that those same errors
cannot result in a legal program sentence.
It turns out that if a semi-colon cannot confuse a program then it need
not be there and its presence or absence is an aesthetic choice for the
programmer (programmers with a semi-colon reflex will put it in anyway).
The point is, however, that the programmer will not spend two weeks trying
to track down a problem caused by an over-enthusiastic semi-colon reflex.
The semi-colon is not the only small mark to take the blame however. In
the original Algol 68 the members of a case clause were serial-units
separated by commas: the inadvertant conversion of a semi-colon to a comma
had strange and unpredictable effects (there are a variety of ways of
accomplishing this feat without hitting the comma key instead of the
semi-colon key). In C, a favourite nasty mistake is to type '=' instead
of '==' when comparing values: this may result in destroying a linked-list
or making some condition always true (this can take hours to track down,
especially in the case where the condition is almost always true). A
particularly nasty mistake in C (which took me three weeks to fix) is
overrunning the end of an array and changing the variable that happens to
to lie next to it in memory--this has little to do with syntax and a lot
to do with semantics.
Finally, take any large Algol 68 program and change a semi-colon in the
top-level scope to a comma. The compilation error `cannot coerce
collateral to void' (in a strong position, for what it's worth), appears
*after* the closing END of the program. This kind of mistaken error
reporting whilst it doesn't result in the accidental compilation of broken
programs does not exactly endear the compiler writer or language designer
to the programmer.
--
John Haxby, Definitively Wrong.
Digital <jch@rdg.dec.com>
Reading, England <...!uknet!wessex!jch>
k
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.