From: Francois Pottier <Francois.Pottier@inria.fr>
To: skaller <skaller@users.sourceforge.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] menhir
Date: Wed, 2 May 2007 20:35:49 +0200 [thread overview]
Message-ID: <20070502183549.GB17473@yquem.inria.fr> (raw)
In-Reply-To: <1178123357.6486.49.camel@rosella.wigram>
On Thu, May 03, 2007 at 02:29:17AM +1000, skaller wrote:
>
> Built an LR(0) automaton with 1416 states.
> Built an LR(1) automaton with 2009 states.
> Warning: 145 states have an end-of-stream conflict.
>
> Can I send you the file?
Sure, please do (perhaps off the list).
> Yes, but you cannot write functions that take a state argument
> because lexbuf is a fixed data type and there's no where to
> add in any user state data.
But my point is that you never need to pass a state argument to a parser
function. Instead, you can just have the function capture the address of the
(mutable) state in its closure.
> EOF is returned an infinite number of times in C.
Point taken.
> This requires the definition: parse the *shortest* head of the
> input stream.
In fact, if there are no end-of-stream conflicts, then the head of the input
stream is *unique*, so you don't need to specify whether you are interested in
a shortest or longest prefix.
> > ocamlyacc never complains. It just trusts you to know what you are doing.
>
> I generate an .output file, grep for the word 'conflict',
> and terminate my build if there is one found. I do not permit
> any conflicts in my grammar: it's strictly unambiguous LALR(1).
Sure, but ocamlyacc does not report end-of-stream conflicts, which I believe
are real issues...
> It's also pure in the sense that it doesn't use crud
> like %left, %prec etc to resolve conflicts.
Good, good!
> [The way dypgen does this is vastly superior!]
How does it work?
--
François Pottier
Francois.Pottier@inria.fr
http://cristal.inria.fr/~fpottier/
next prev parent reply other threads:[~2007-05-02 18:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-28 10:32 menhir skaller
2007-04-28 16:50 ` [Caml-list] menhir Francois Pottier
2007-04-28 19:47 ` Markus Mottl
2007-04-28 21:15 ` Jon Harrop
2007-04-29 4:43 ` skaller
2007-04-29 7:27 ` Christophe Raffalli
2007-05-01 15:57 ` Francois Pottier
2007-05-01 17:11 ` skaller
2007-05-01 17:34 ` Francois Pottier
2007-05-01 23:42 ` skaller
2007-05-02 5:38 ` Francois Pottier
2007-05-02 5:50 ` Francois Pottier
2007-05-02 8:41 ` skaller
2007-05-02 12:30 ` Francois Pottier
2007-05-02 16:29 ` skaller
2007-05-02 18:35 ` Francois Pottier [this message]
2007-05-03 1:30 ` skaller
2007-05-03 8:43 ` Joel Reymont
2007-05-01 17:15 ` skaller
2007-05-01 17:31 ` Francois Pottier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070502183549.GB17473@yquem.inria.fr \
--to=francois.pottier@inria.fr \
--cc=caml-list@inria.fr \
--cc=skaller@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox