Hello,

On Sun, Apr 29, 2007 at 02:43:03PM +1000, skaller wrote:
> > An option to generate tables like ocamlyacc would clearly be useful.
> 
> Although that defeats one of the future advantages of Menhir:
> embedding. To understand what I mean you might look at the Felix
> parser generator. In Felix you can write parsers in any scope,
> and the user actions bind to the containing scope.

I don't see why there is a relationship between the style of code
generation (code versus tables) and embedding.

Embedding in Menhir is supported indirectly via %parameter directives.

> It is possible (but I'm no expert!!) that the non-linearity
> in compiling Menhir generated code is due to a very 
> large let rec/and/... being generated. Some extra analysis 
> might fix that, i.e. using recursion only when necessary,
> and let/and/in otherwise (though I have no idea how to
> do that).

I have tried that, but it does not help. Most (say, 95%) of the functions
generated by Menhir are truly mutually recursive.

> So the conflicts are spurious: end of stream can't be parsed
> (but of course Menhir doesn't know that). This is good,
> because Mehir CANNOT detect end of stream, since my lexbuf
> is a dummy and is not used at all.

Perhaps the terminology "end-of-stream conflict" is badly chosen. These
conflicts are not just about detecting the end of the stream: they are about
recognizing a non-terminal symbol without overshooting, that is, without
unnecessarily requesting a lookahead token (a request which, if the end of
stream has been reached, could be unsatisfiable, or could be blocking).

These conflicts are not "spurious": just like shift/reduce or reduce/reduce
conflicts, they will cause trouble.

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