Re: language design implications for variant records in a pascal-like language

George Neuner wrote:


> Why do so many languages offer (at least) two forms of conditional
> loop: one with the test at the beginning and another with the test at
> the end? Why not just offer an infinite loop and a way to break out
> that can be tied to any conditional?


Because they behave differently. When you test at the entry point to
a loop, the loop may run zero or more times. When you test at the
end of the loop, just before the jump back to the beginning, you have
a loop that will run one or more times.


This is why I shuddered with horror when I read that BBC Basic had
REPEAT/UNTIL but no WHILE/WEND. I envisiged a host of bugs. Sure,
you can write a REPEAT/UNTIL loop and put an IF/ENDIF around the
code within it, but that's extra code and my cynical observation, even
back then, was that most programmers would wish to make their code
as short as possible. This was esp important in a token-based interpreter,
as most Basic implementations on small machines like the BBC Micro.
Every token was expensive, not just in memory terms, but also in run-time.
Code optimisations would therefore include rearranging the order of the
lines, placing frequently run code at the start of the program, to give them
low line numbers, and using short variable names. Removing a line
completely was the ultimate optimisation.


So I further imagined a generation of programmers being encouraged to
write code like this in *any* language, on *any* machine, out of habit.
Ironically, I saw GOTO as the least destructive feature of the language.


The old argument for leaving out certain language features was the finite
amount of memory available, in this case in the BBC Micro's ROM. I later
read about some other features that I'd have happily sacrified to make
room for WHILE/WEND support.


Another small point: almost every conditional loop I'd written up to that
put had been a WHILE loop, not a REPEAT loop. This was true even when
I wrote code in assembly language. It wasn't decided by any choice of
language features; it was simply the right control structure for the code.
Anything else would've been a bug. Several decades later, I still find that
I'm writing zero-or-more loops, and *very* rarely one-or-more.


WHILE/WEND:
"As there any work to be done? If so, do that work."


REPEAT/UNTIL:
"Do some work, then see if there's any more to be done."


This simple distinction helped me write much better code, even in
assembly language. ;) Imagine the task of picking items off a linked
list and processing the items in sequence. If you failed to use the
right control structure here, your code will likely crash and do
something very odd when the list is empty. Also consider code that
reads text from a file - what will happen when the file is empty? Will
your code cope? How will it fail, gracefully or painfully?


I don't believe this is an academic language design issue. It has
serious real-world effects, including bugs. I first read about it in
the Software Tools books (both of them). It also turns up in a lot of
academic literature, but that doesn't make it a purely academic issue
- it only means that it's so serious that even academics are aware of
it. ;)

Return to the comp.compilers page.
Search the comp.compilers archives again.