Related articles |
---|
[7 earlier articles] |
Re: language design tradeoffs macrakis@osf.org (1992-09-15) |
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-15) |
Re: language design tradeoffs anw@maths.nott.ac.uk (1992-09-16) |
Re: language design tradeoffs drw@euclid.mit.edu (1992-09-16) |
Re: language design tradeoffs rob@guinness.eng.ohio-state.edu (1992-09-17) |
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-17) |
Re: language design tradeoffs jch@rdg.dec.com (1992-09-17) |
Re: language design tradeoffs firth@sei.cmu.edu (1992-09-17) |
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-17) |
Re: language design tradeoffs norvell@csri.toronto.edu (1992-09-17) |
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-17) |
Re: language design tradeoffs bks@s27w007.pswfs.gov (1992-09-17) |
Re: language design tradeoffs raveling@Unify.com (1992-09-17) |
[21 later articles] |
Newsgroups: | comp.compilers,comp.human-factors |
From: | jch@rdg.dec.com (John Haxby) |
Organization: | Digital Equipment Corporation |
Date: | Thu, 17 Sep 1992 10:37:02 GMT |
References: | 92-09-048 92-09-095 |
Keywords: | design |
The trouble with terminators or separators is that when they are omitted
(by accident) is that the meaning of the program changes. Somethings the
meaning is broken and the program no longer compiles, sometimes it is
broken and no longer runs, sometimes it is broken and still, almost works.
Two examples I have come across are:
while (long and complicated thing);
modify thing;
This just spins. I usually generate these when I decide that
long-and-complicated-thing has got out of hand and I put part of it in the
body of the loop, forgetting that same is already empty. There are a
number of ways out of this, most of them provided by Algol 68, where the
second example comes from (courtesy Andy Walker):
while doobry1 do thing1 od doobry2 do thing 2 od
This can be broken in a couple of interesting ways (it is illegal as it
stands):
while doobry1; do thing1 od; doobry2 do thing2 od
In this case, `thing1' is done for ever and when it finishes, doobry2 is
used as the control for the loop containing thing2. doobry1 has nothing
to do with it. The other way is
while doobry1 do thing1 od; doobry2; do thing2 od
In this case, while ever doobry1 is true, thing1 is executed, then doobry2
is executed and finally thing2 is executed for ever.
Usually you are lucky and the wrong control variables can't be coerced to
bool and the program doesn't compile although 'cannot coerce doobry2 to to
bool' is a poor approximation to 'spurious semi-colon after doobry1' (I'll
gloss over the details of how you get yourself into this mess.)
If, on the other hand, the language is designed so that the terminators
add nothing to the program, it doesn't matter where you put them (although
they can only be put in legal positions), and you can, if you prefer,
leave them out. CLU certainly works this way and, I believe, so does
Modula 3 (although M3 requires the semi-colins, it doesn't need them).
There are some important consequences of this. The first, and most
obvious is that you need begin-end pairs (regardless of how you spell
them). So, for example,
if this
then if the_other
then wotsit
end
else thingy
end
is unambigious (if meaningless). The `end' is what CLU uses, although I
still hanker after `fi'. The other criterion is that constructs like
'68's do...od should be avoided because it is the position of a semi-colon
that determines which control clause, if any, is controlling the loop.
You can, if you think it makes the program clearer, put semi-colons in--I
usually do if I have two statements on the same line (if I ever do).
Whether I put them in or leave them out makes no difference to the
compiler. The net result of this is that whilst missing semi-colons are
the bane of my life when writing C, I don't have that problem with CLU (I
just miss them all out).
With careful language design you can avoid features that cause problems
for programmers: semi-colons are the obvious target given their ability to
generate amusing stories for those long, drawn out Friday lunchtimes. On
second thoughts, leave them in :-)
--
John Haxby, Definitively Wrong.
Digital <jch@rdg.dec.com>
Reading, England <...!uknet!wessex!jch>
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.