Christian Lindig wrote:

> > 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.

Adding the tokens to the .mly file is a pain.
I have two other files which also need to list all tokens:
one to print them, and one to extract the source file/line/column
information. Both have to be manually tracked anyhow.

Worse, the %token command makes a normal union: how to use
polymorphic variants instead?

Even worse, the lexer and parser are improperly connected,
with the parser incorrectly taking a lexer and lexbuf as
arguments -- a right pain if you want to preprocess the
tokens. I have to create a dummy lexbuf/lexer to drive
the parser. The parser should take a callback function
as an argument. A patch to make this alternative calling
technique available would be useful.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net
-------------------
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