NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/compiler/1547

Internet Message Format | 1992-09-12 | 3.3 KB

Xref: sparky comp.compilers:1547 comp.human-factors:2200
Newsgroups: comp.compilers,comp.human-factors
Path: sparky!uunet!world!iecc!compilers-sender
From: [e-mail] (Paul Raveling)
Subject: Re: language design tradeoffs
Reply-To: [e-mail] (Paul Raveling)
Organization: Unify Corporation (Sacramento)
Date: Fri, 11 Sep 1992 20:00:21 GMT
Approved: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Keywords: design, parse, comment
Sender: [e-mail]
Lines: 75

[e-mail] (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
[e-mail]
[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]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.