Browse thread
[Caml-list] On ocamlyacc and ocamllex
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2001-09-23 (20:09) |
From: | Christian Lindig <lindig@e...> |
Subject: | Re: [Caml-list] On ocamlyacc and ocamllex |
On Sun, Sep 23, 2001 at 10:32:23PM +0300, Vesa Karvonen wrote: > From: "Christian Lindig" <lindig@eecs.harvard.edu> > I'd prefer that the lexer generator would be extended so that additional > arguments could be added in a manner similar to this: > > rule token map = parse > eof { P.EOF } > | ws+ { token map lexbuf } > | tab { tab map lexbuf; token map lexbuf } > | nl { nl map lexbuf ; token map lexbuf } > | nl '#' { line map lexbuf 0; token map lexbuf } > ... I lobbied for this three years ago and had a patch for ocamllex: http://www.eecs.harvard.edu/~lindig/software/lex-patch.html > Can this technique be used for adding context to parsers generated > using ocamlyacc, too? I'm not sure what you mean here. A Yacc parser works bottom up - do you want to inject "context" into the tokens that are received from the lexer? > I agree that it may be somewhat easier for the parser generator, but I > find that separating the token type definition from the grammar > definition can be justified using quantitative technical arguments. I agree that this alternative avoids the dependency of the type definition on the grammar. But I am not sure that manually keeping the type definition and the %token declarations in the parser in sync is better than automatic recompiles or a little Make hack. -- Christian -- Christian Lindig Harvard University - DEAS lindig@eecs.harvard.edu 33 Oxford St, MD 242, Cambridge MA 02138 phone: +1 (617) 496-7157 http://www.eecs.harvard.edu/~lindig/ ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr