Hello,

On Sat, Apr 28, 2007 at 08:32:16PM +1000, skaller wrote:
> Second, I got a "rather a lot" of states have end-of-stream conflicts.
> What's that about?

That's precisely about "overshooting" the end of the token stream (reading
one too many tokens). The issue is described in the manual.

> Third the generated ml file was 4.5 Meg.  Ocamlopt on amd64 hung for so long
> I almost posted a bug report for Ocamlopt, but finally it finished.

Yup, I am somewhat disappointed that ocamlopt does not seem to have linear
time complexity, but I shouldn't complain too loud, my boss may be listening
:)

An option to generate tables like ocamlyacc would clearly be useful.

> Basically: when Ocamlyacc reduces a production, it sometimes
> ends on the last token, and sometimes it overshoots by 1.

I don't know the details of your grammar, but our (perhaps naive) view is that
you should modify your grammar to avoid end-of-stream conflicts (and Menhir's
conflict reports will help you do that). Then, Menhir will not overshoot.

> The semantics used are: when the exprx is processed the
> action arranges to push the terminator token back
> into the token stream.

How is this done? It is possible that this hack is not compatible with Menhir,
because Menhir keeps a local cache of the next token, which is not properly
updated when you push your old token back.

-- 
François Pottier
Francois.Pottier@inria.fr
http://cristal.inria.fr/~fpottier/