<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-html" lang="x-western"> On 10/23/08 03:23, Joel
<pre wrap="">On Thu, Oct 23, 2008 at 12:18 AM, Pranesh Srinivasan <a
class="moz-txt-link-rfc2396E" href="mailto:email@example.com"><firstname.lastname@example.org></a> wrote:
<pre wrap="">That seems like a very nice scheme to follow. I had a similar method in
mind. Step 3 is what I am really worried about. How easy/difficult will
it be in a pure func language, to "transform" the sytnax tree.
I think the pureness is actually an advantage here, since the
transformation is a function from one syntax tree to another. If
however, you feel the need of keeping a state and you don't wanna pass
around this explicitly, you may consider using a state monad.
<pre wrap="">I have to take a deeper look at BNFC. But from an initial look, it seems
way too powerful for me to use? At least as powerful as yacc. And that
with Haskell, should give me a very good toolset-advantage?
If the project is about writing parsers then using BNFC would probably
be considered cheating. But for practical purposes I think it's a
great tool that would save you a lot of work.
Does BNFC calculate the lookahead sets for a grammar?<br>
I'm attempting to do this with haskell, but I would hate<br>
to "reinvent the wheel". I would think if haskell can tranform<br>
a syntax tree, then haskell could transform a grammar tree<br>
to calculate the lookahead sets. My purpose it not so much<br>
create a compiler as illustrate how it's done. I found the<br>
Dragon's book description hard to follow and thought<br>
redoing it using functors (to transform the tree into<br>
another, with different operators) then simplify the<br>
transformed trees (one tree for each lookahead set)<br>
then find the fixpoint of those trees (really forest:<br>
1 tree for each production) would be a good way<br>
to demonstrate the method.<br>