Related articles |
---|
Why separate Lexical & Parser Generators heronj@smtplink.NGC.COM (John Heron) (1994-10-05) |
Re: Why separate Lexical & Parser Generators morrison@hal.cs.uiuc.edu (1994-10-07) |
Re: Why separate Lexical & Parser Generator steve@cegelecproj.co.uk (1994-10-10) |
Newsgroups: | comp.compilers |
From: | steve@cegelecproj.co.uk (Steve_Kilbane) |
Keywords: | lex, yacc, comment |
Organization: | Compilers Central |
References: | 94-10-028 94-10-058 |
Date: | Mon, 10 Oct 1994 11:26:01 GMT |
Vance Morrison writes:
> Another problem is dealing with comments because they can occur ANYWHERE.
> This can be solved by simply restricting where comments can go (which may
> not be a bad idea in any case).
Would have made my life easier. The project I'm involved in implementing a
standard which has graphical and textual versions of a language. A pretty
X editor creates the graphical version, and saves it as the textual
version, which is later compiled. All is well and good until you wish to
reload the the textual version into the editor to make a change, and boom!
There go all your comments. Not nice, and it's a fairly old problem
(pretty printers and static analysers have this trouble, too).
The (rather weak) solution we adopted was to overload comments. Since they
are delimited by (* ... *), we decided that any comment delimited by
(** ... **) would be converted into a token, and (hopefully) accepted by
the parser. Not nice, but it works, for now.
Steve
[An approach I've used is to have fat tokens where each token carries along
any comment text that precedes it. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.