Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: zortech problem with lex
Message-ID: <260A9B1D.17399@paris.ics.uci.edu>
Date: 23 Mar 90 21:54:38 GMT
References: <6300008@ux1.cso.uiuc.edu> <24800002@sunb6> <25ECE752.29589@paris.ics.uci.edu> <10541@alice.UUCP> <6553@cadillac.CAD.MCC.COM> <25F8C92A.9349@paris.ics.uci.edu> <3742@tukki.jyu.fi> <26073795.10139@paris.ics.uci.edu> <PCG.90Mar23120003@odin.cs.aber.ac.uk>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 46

In article <PCG.90Mar23120003@odin.cs.aber.ac.uk> pcg@odin.cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>In article <26073795.10139@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald
>Guilmette) writes:
>
>   If you are willing to do just a few more things with semantic analysis
>   rather than syntax analysis (relative to what current C++ implementors
>   seem to be doing) then you can in fact have a useful and practical LALR(1)
>   grammar for C++.  That was my point.  I just stated it badly.
>
>Sorry Ron, but we really still disagree on a question of terminology
>here; a LALR(1) grammar belongs to the context free class. If you need
>semantic information to parse C++ (and by all means you need it) then
>your intelligent lexer is also a translator from a context sensitive
>C++ to another language that is indeed LALR(1), BUT IS NO LONGER C++.
>
>In particular this language has typedef names as tokens/keywords for the

That (I claim) is a design decision on the part of the implementor.  (And
we are now getting down to the meat of my point.)

I fully admit that C and C++ are easier to "compile" if you have separate
token types for "identifier" and for "type name", but is this absolutely
manditory?  I think not.  Without having such distinctions made at the
lexical level (or the basis of feedback from semantic analysis), you will
of course end up with excessively general non-terminals like (for instance):

	declarative_or_executable_statement:

whose corresponding rules will allow stuff like:

	F ( Y ) = Z;

even in cases where (semantically) the context demands that F be treated
as the name of a function, but (as I said before) that just means that
you gotta do more work in the semantic analysis to properly detect and
flag such errors.

(Footnote: Actually, that may be a bad example, because I think that even
if "F" is the name of a function, the above statement may be legal, e.g.
in cases where F returns a reference.)


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.