Re: language design tradeoffs (Paul Raveling)
Fri, 11 Sep 1992 20:00:21 GMT

          From comp.compilers

Related articles
language design tradeoffs (1992-09-07)
Re: language design tradeoffs (1992-09-08)
Re: language design tradeoffs nr@dynastar.Princeton.EDU (1992-09-09)
Re: language design tradeoffs (1992-09-11)
Re: language design tradeoffs (1992-09-13)
Re: language design tradeoffs (1992-09-14)
Re: language design tradeoffs (1992-09-14)
Re: language design tradeoffs (1992-09-15)
Re: language design tradeoffs (1992-09-15)
Re: language design tradeoffs (1992-09-16)
[31 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.human-factors
From: (Paul Raveling)
Organization: Unify Corporation (Sacramento)
Date: Fri, 11 Sep 1992 20:00:21 GMT
References: 92-09-048 92-09-052
Keywords: design, parse, comment (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 )

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 )

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

But the whole thing isn't a problem if an unescaped EOL is a statement
Paul Raveling
[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

Post a followup to this message

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