NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18631

Text File | 1993-01-02 | 3.3 KB | 80 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: template disappointments ... (suggestions?)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 2 Jan 1993 08:14:10 GMT
Lines: 67

In article <[e-mail]> [e-mail] (Steve Clamage) writes:
>[e-mail] (Eric Smith) writes:
>
>>In article <[e-mail]> [e-mail] (Steve Clamage) writes:
>>How is >> different from > in that respect?  a>b is a perfectly valid
>>int expression.
>
>The '>' is always a '>' token.  The proposal was that sometimes '>>' is
>a '>>' token and sometimes it is two '>' tokens.

    It doesnt have to be construed that way. One could just
extend the grammar to allow the single >> to terminate two levels of open
< brackets.

>The compiler would have
>to decide which interpretation to use.  One interpretation might wind up
>being unparseable only after an arbitrary number of additional tokens.

    The compiler has this same problem parsing '-' in the sense
that it might be a single token "unary or binary minus" or two
different tokens "unary minus" or "binary minus".
>
>Suppose there are several sets of '>>' in a template expression.  Each
>one is a branch point for additional possible parses.  The compiler has to
>verify that exactly one of a set of interpretations leads to a valid parse.

    How does this differ from '>' already causing the same problem?
>
>A whole new kind of parsing is therefore required just to allow
>programmers to omit a blank between consecutive closing template brackets.

    You may be right, indeed it appears to me you are,
but the technical question is probably whether '>>' could mean
"shift or double template right bracket" and still be parsed
using an LALR parser. (Is there an LALR grammar for C++ anyhow?)

>
>It isn't impossible to have a language like this.  The question, as
>always, is whether the additional compiler complexity and other
>disadavantages are outweighed by the advantages.  The decision in C
>and C++ has always been to choose context-free lexical analysis and
>the "maximum munch" lexical rule.

    The lexical analyser would be regular surely, not context
free, and the parser hopefully less than context free: a backtracking
parser would have no problem with '>>', but the users waiting
hours for a compile might :-)

    It is surely easy to make a rule that when two levels
of < have been seen, they are closed by >>. If you really
want a shift, use brackets.

    < ... < ... >>

    < .. < ... (a>>b) .. >>

    This sort of rule is already in place for the stupid
comma operator. I'm certainly not suggesting we do this,
but it would be interesting to establish whether '>>'
can be implemented using the same sort of parsers
currently used for C++.

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------