Re: language design tradeoffs

os360051@wvnvms.wvnet.edu (T. Kurt Bond)
Sat, 26 Sep 1992 01:43:58 GMT

          From comp.compilers

Related articles
[33 earlier articles]
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-23)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-23)
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-24)
Re: language design tradeoffs alvin@eyepoint.com (1992-09-24)
Re: language design tradeoffs rob@hoster.eng.ohio-state.edu (1992-09-24)
Re: language design tradeoffs chased@rbbb.Eng.Sun.COM (1992-09-25)
Re: language design tradeoffs os360051@wvnvms.wvnet.edu (1992-09-26)
Re: language design tradeoffs plyon@emx.cc.utexas.edu (1992-09-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: os360051@wvnvms.wvnet.edu (T. Kurt Bond)
Organization: West Virginia Network for Educational Telecomputing
Date: Sat, 26 Sep 1992 01:43:58 GMT
Keywords: design, syntax, Basic
References: 92-09-122 92-09-162

jlg@cochiti.lanl.gov (Jim Giles) writes:
>In fact the only evidence available tends to the other conclusion - that EOL
>*should* be the usual statement terminator. Whether you consider this
    ^^^^^^^^
>evidence strong or weak, it's the only evidence there is.


rob@hoster.eng.ohio-state.edu (Rob Carriere) writes:
> True, [but not conclusive]


The language that I use every day at work uses EOL as the statement
terminator and uses a continuation character (the & character) at the end
of a line to continue multi-line statements. The language? VAX BASIC.
(Before you gasp in disgust at the mention of BASIC and skip the rest of
this, consider that VAX BASIC has structures, seperately compiled
functions and subprograms, exceptions, and doesn't require you to use line
numbers.)


I checked the source code for a commercial flat file manager we use for
continued lines. Out of 233548 source lines, 43341 lines were continued,
or 18.5 percent. I checked the source code for a report generation
language compiler I wrote (a recursive descent parser written in VAX BASIC
that generates VAX BASIC :-) for continued lines: out of 9015 source
lines, 691 were continued, or 7.6 percent. I checked another product we
are writing; out of 47465 lines, 3832 were continued, or 8.1 percent.


VAX BASIC comments extend from an exclamation mark to the end of the line.
When you comment a continued line, where do you put the comment: before
the continuation character, because the continuation character has to be
at the end of the line, or after the continuation, because comments are
ignored? VAX BASIC chooses the former, and many're the beginning VAX
BASIC programmer who assumes it is the other way. (``If you put the
continuation in the comment, won't it be ignored?'')


In the things I write I deliberately attempt to avoid continued lines, if
I can, because it seems that when I edit continued lines I usually end up
changing where the line is broken and so have to move the continuation
lines around. (It may be trivial, but it is frustrating in practice. One
thing about semicolons as terminators, once you have them in the correct
place you rarely have to move them during editing.)


Of course, VAX BASIC also has an explict statement seperator, for when you
want to put several statements on one line: the `\' character. Combining
that with the `&' (under the influence of RSTS BASIC and the interactive
BASIC environment, I think) can lead to the following coding style:


if something then &
\ call do_something ! A comment &
\ if something_else then &
\ call do_it &
\ call do_other &
\ else &
\ call whatever &
\ x = 1 &
\ end if &
\ end if &


instead of


if something then
call do_something ! A comment
if something_else then
call do_it
call do_other
else
call whatever
x = 1
end if
end if


which is much easer to read. Why would anybody use the former? Well,
part of that flat file manager I mentioned above allows the user to enter
BASIC source code, which is preprocessed to handle references to fields in
the field then compiled and executed on each record in the file. Its
parser usually silently misparses the forms like the later, but always
parsers forms like the former correctly. Now admittedly this is an error
in the parser, but the fact that it has persisted for years suggests that
it's tricky to change the parser to handle both correctly. Certainly
using continuation characters seems to make the simple tools I use to
generate or preprocess VAX BASIC somewhat harder to write than similar
tools I write for C.
--
T. Kurt Bond, tkb@mtnet2.wvnet.edu or os360051@wvnvms.wvnet.edu
--


Post a followup to this message

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