2nd Annual Obfuscated Contest Winners

[Morris M. Keesan]

In article <217 at uthub.UUCP> thomson at uthub.UUCP (Brian Thomson) writes:
>From Morris Keesan (keesan at bbnccv):
.
.
>>A little examination reveals that the error reduces to
>>
>>	expr ? expr , expr : expr
>>
>>which is illegal because the comma operator has lower precedence than the
>>conditional operator.
>
>No, I think you're wrong.  The relative precedence of operators exists only
>to disambiguate possible parses.  In the example you cite there is only
>one valid parse, so precedence doesn't come into it.  The "bug", if you
>want to call it that, exists in your compiler rather than in PCC.
-----------------------------------------------------------------------------
    Well, if we were discussing this from the viewpoint of language philosophy
and language design, I would probably agree with you that operator precedence
SHOULD only exist to disambiguate possible parses.  However, this is not the
case in C.  I quote from the C Reference Manual, section 7 (p. 185 of K&R) 
[ I am using the symbol '#' here as a replacement for the 'section' symbol,
which is not in the ASCII character set]:

        The precedence of expression operators is the same as the order of
    the major subsections of this section, highest precedence first.
    Thus, for example, the expressions referred to as the operands of +
    (#7.4) are those expressions defined in ##7.1-7.3.

The conditional operator (?:) is defined in section 7.13, and thus the
expressions which may be its operands are those defined in subsections 7.1
through 7.12.  By the above paragraph, the expressions defined in subsections
7.14 (assignment expressions) and 7.15 (comma expressions) are explicitly NOT
allowed as operands of the conditional operator, and so the expressions

    a ? b , c : d
    a ? b = c : d
    a ? b : d = c

although perfectly plausible and unambiguous, are not valid expressions in
any formally-defined version of C (K&R, V7 UNIX, System V, 4.2BSD, Ultrix,
and the various ANSI Draft Proposed Standards all agree on this in their
documents defining C -- the ANSI draft is clearest).

Just because there is only one possible or plausible parse that doesn't make it
a valid parse.

>PCC-based compilers use a more powerful technique [LALR(1)] for
>expression parsing than does the Ritchie compiler [simple precedence, if
>I remember rightly], and the simpler technique can't quite hack
>the language.

The simpler technique "hacks the language" exactly, and is probably the
rationale for the language being defined the way it was.  The "more powerful
technique" being used by PCC is power misapplied, and is accepting
expressions which are not allowed by the language definition (unless you
define the language as "what the compiler accepts").
-- 
Morris M. Keesan
keesan at bbn-unix.ARPA
{decvax,ihnp4,etc.}!bbncca!keesan