Re: lex/flex incompatabilities

vern@daffy.ee.lbl.gov (Vern Paxson)
Mon, 7 Oct 91 17:58:44 GMT

          From comp.compilers

Related articles
lex/flex incompatabilities jk@cs.man.ac.uk (1991-10-04)
Re: lex/flex incompatabilities cadreor!neil@uunet.uu.net (1991-10-05)
Re: lex/flex incompatabilities bart@cs.uoregon.edu (1991-10-06)
Re: lex/flex incompatabilities Tony_Mason@transarc.com (1991-10-07)
Re: lex/flex incompatabilities vern@daffy.ee.lbl.gov (1991-10-07)
| List of all articles for this month |
Newsgroups: comp.compilers
From: vern@daffy.ee.lbl.gov (Vern Paxson)
Keywords: lex, flex, FTP
Organization: Lawrence Berkeley Laboratory, Berkeley
References: 91-10-014
Date: Mon, 7 Oct 91 17:58:44 GMT

In article 91-10-014 jk@cs.man.ac.uk (John Kewley ICL) writes:
>The version of flex that I have disallows the %a %p, ... directives needed
>when I use lex.


Your flex version is out-of-date. The last couple full releases have
ignored %<letter> directives and have a bunch of other changes to support
closer compatibility with lex (and, more to the point, with the draft
POSIX lex standard). You can get the latest release via anonymous ftp to
ftp.ee.lbl.gov (128.3.112.20; retrieve flex-2.3.7.tar.Z, using binary mode),
or from your neighborhood GNU ftp site. If you don't have anonymous ftp, I
can mail you the uuencoded tar file.


>Apart from yywrap (needs undefing if defined) what other problems might I
>have with flex/lex compatibility.


All of the known areas of incompatibility are documented in "flexdoc.1",
included in the release.




cadreor!neil@uunet.uu.net (Neil Van Dyke) writes:
> >Apart from yywrap (needs undefing if defined) what other problems might I
> >have with flex/lex compatibility.
>
> Appendix D of "lex & yacc", O'Reilly & Associates, includes:


Please note that the list given in the book is very out-of-date.




bart@cs.uoregon.edu (Barton Christopher Massey) writes:
> On the other hand, probably the single biggest compatibility
> mistake for me is that
>
> - Flex doesn't understand the beginning-of-line operator "^"
> or end-of-line operator "$" inside parens -- including the
> implicit parens resulting from expansion -- so
> LABEL ^[A-Z][A-Z0-9]*
> COMMENT ";".*$
> %%
> {LABEL} printf("Matched.\n");
> {COMMENT} printf("Comment.\n");
> will match the lines "FOO" or "; comment" in LEX but not in
> FLEX.


Yes, this is a particularly ugly flex wart. Fixing flex to understand
'^' and '$' inside parens is a headache (or else I would've done it!).
But perhaps it's worth special-casing situations like the ones in the
example above, where the {definition} is the entire rule, and not literally
enclose those values in parentheses; while it's a slight inconsistency, it
strikes me as closer to the principle of Least Surprise ...


> P.S. -- When do we get released FLEX bits that build C code
> instead of tables for the automata? I've been eagerly awaiting
> this one...


I'm afraid this project is in limbo. I haven't heard from the guy who
was working on it for a long while.


Vern
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.