Re: language design tradeoffs

torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>
> Several languages (e.g. Miranda) use EOL as separator. It gives an
> uncluttered syntax, but requires special structure if command or
> expressions can't fit on a line.


Once long ago this was considered easier than using a terminator such as
';' -- a prime example was FORTRAN. How many remember the thrill of
having their IBM FORTRAN II compiler patched to recognize record-mark (a
0-2-8 punch) as a statement terminator, making it possible to punch TWO
statements per card?


For a more modern and widespread example, there's the C preprocessor,
where macros are parsed as one line, though they're often written as
multiple lines ending with '\'.


Actually I like the idea of using EOL rather than ;. It eliminates a
cause of several common errors in compilation that need not happen, and it
need not have particularly adverse side effects.


Here's one example of a human factors trap in C that wouldn't be there
without ';'. The key is C's syntax definition for <statement> -- either
one simple statement terminated by ';' or a sequence of simple statements
surrounded by {}'s.


#define SOME_MACRO(A,B) \
xxx; /* one simple C statement */


is syntactically interchangeable with:


#define SOME_MACRO(A,B) \
{ xxx; yyy; } /* one compound C statement */




Now take this invocation:


if ( a == b )
SOME_MACRO(a,b)
else
...


But if your brain kicked in with the notion that SOME_MACRO(a,b)
invocation looks like it should be a statement, and you automatically
coded it as


   if ( a == b )
SOME_MACRO(a,b);
else
...


then the extra ';' terminates the entire 'if' statement and the following
'else' produces a syntax error. Or if you had left yourself open to the
dangling else problem in nested if's, it's possible to get no syntax error
but instead to get a surprising flow of control.


There's a second-level trap here too, based on using knowledge of
semicolons in software tools. I once saw someone encounter the trap above
when his automatic-indenting software demanded that the macro invocation
look like a statement, ending with a ';'. To accommodate this autoindent
software he took existing code that had been correct and appended a ';' to
each macro invocation. At least it caused no harm on MOST of the macro
invocations...


But the whole thing isn't a problem if an unescaped EOL is a statement
terminator.
------------------
Paul Raveling
Raveling@Unify.com
[For people who don't know, there are straightforward albeit ugly ways around
the if, macro, and semicolon problem, e.g.:
#define foo(args) if(1) { /* macro body */ } else
-John]
--

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