[Ometa] preventing left recursion, Grow-LR

[Alessandro Warth]

Hi Justin,

I was just reading your PHD dissertation on OMeta on the chapter regarding
> the prevention of left recursion. In figure 3.3 you give psuedo code for a
> Grow-LR function but leave out a few lines saying that they can be ignored
> for the moment. Later you explain how to refine the Apply-Rule function to
> support indirect left-recursion but in figure 3.8 you reference the Grow-=
LR
> function without providing an updated, complete Grow-LR.
>
> Am I missing something there? What are the missing lines from Grow-LR or
> why wasn't an updated version provided along with figure 3.8?
>

The missing lines are provided in section 3.3.4 (Adding Support for Indirect
Left Recursion) -- just take a look at the bottom of page 54 and page 55.

But as for the chapter in general I'm incredibly impressed. I was litterally
> just thinking about how to solve this problem and read this chapter and I
> understood almost everything up to the end. This is a seriously brilliant
> piece of work and it will save me a lot of time since I don't have to
> re-figure it all out. Thank you very much.
>
> In case you're wondering what I'm working on, I've been working on a
> project for a while now called MetaSharp which was formerly a tool to
> compliment the new Microsoft MGrammar tools. After doing some research and
> reading about OMeta I have realized that OMeta is actually the logical
> conclusion to the core concepts I have been independently coming up with =
as
> well. My reliance on MGrammar however was preventing me from going all the
> way down the rabbit hole and realizing the full implications like you hav=
e.
> Reading your dissertation has been revelatory.
>
> In your document you say "OMeta=92s key insight is the realization that a=
ll
> of the passes in a traditional compiler are essentially pattern matching
> operations". I think this is the most important statement in the whole
> document. What you have been calling Pattern Matching I have been calling
> Transformation. You have made me realize that the Transformation pattern =
is
> a super set of the State Machine and Visitor patterns as you explained. T=
his
> completely blew my mind. I had been relying on MGrammar to do all of my
> textual parsing but that still leaves the process of transforming the
> resulting AST into something meaningful. Reading that sentence of yours
> suddenly made me realize that transforming text was litterally the exact
> same concept as transforming objects and that I could create one core
> library that was the basis for all of the phases of the compiler.
>
> And what is really blowing my mind is the realization that with these too=
ls
> in hand you can express other design patterns as DSLs, therefore with this
> one pattern you can express any application as layers of abstractions...
> completely generative domain driven applications. I don't think its an
> exaggeration to say that the ideas put forth here in OMeta are a unifying
> theory of compilation. I have not been formally trained in compilers so
> maybe I'm letting my excitement get away with me but reading your work has
> been revelatory for me, so at the very least you should be proud to have
> inspired one person. I hope I'm making some sense here, though I'm sure
> you've come to similar conclusions long ago. Thank you very much for your
> work!
>

You're welcome, I'm glad you've found it useful!

Cheers,
Alex


>
> --
> Justin Chase
> http://www.justnbusiness.com
>
> _______________________________________________
> OMeta mailing list
> OMeta at vpri.org
> http://vpri.org/mailman/listinfo/ometa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://vpri.org/pipermail/ometa/attachments/20091205/9f46b874/attachme=
nt.htm