Browse thread
menhir
[
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: | 2007-05-01 (15:57) |
From: | Francois Pottier <Francois.Pottier@i...> |
Subject: | Re: [Caml-list] menhir |
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/