Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: LEX
Message-ID: <828@PT.CS.CMU.EDU>
Date: 8 Feb 88 15:11:57 GMT
References: <3703@megaron.arizona.edu> <248@goofy.megatest.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 61

> > I'm writting a C like language to discribe data structures.  When I
> > was writting the tokenizer using LEX and I got intrigued by a little
> > problem.  Is it possible to write a regular expression that will
> > transform a /* comment */ into nothing?
>  
> It is indeed intriguing.   I don't think you can write any
> LR(k) context-free grammar to "transform it" into anything.
> 

  I don't think you should be concerned with trying to put comment handling
in the grammar.   It is usually the job of the lexer to strip comments
out of the source code which is a very easy task.

  A comment in regards to the question about handling an ambiguity in
the C grammar.  The problems was that there are cases where a
variable declaration could be confused with a function call.
Example:

	typedef int xx;
	main()
	    {
	    xx (x);
	    .....
	    }

 The statement xx (x) could be parsed as either a variable declaration
of x or a function call of xx and is depended upon the context
(whether xx is a function or a type).

   If you change our grammar to distinguish between the to you should
have no problems. 


	funcbody	:	varlist statements
			;

	varlist		:	varlist vardec
			|	/* epsilon */
			;

	vardec		:	TYPENAME varexp;
			;

	statements	:	FUNCNAME arglist
			|	......

    In the lexer, one would have to distinguish ids of function calls
from ids of typedefs and return the tokens FUNCNAME or TYPENAME
respectively.  This can be done simple by doing a lookup in the 
type name table , followed by a lookup  in the func name table if
the lookup in the type name table fails.  I think the semantics
of C will require that order execution.  If the lookup in the
type name table succeeds then the id has to be a type name,
a function could not have a name the same as the typedef id,
or should I say my C compiler flags this one.  If the
lookup in the type name table fails the statement has to be a function
call.   If the lookup in the func name table fails, insert it
into the table as a forward reference to the function.
-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu