From: Markus Liedl <m.liedl@...>
Date: 2007-11-17T18:15:00+09:00
Subject: Re: Alternative Ruby grammar

On Nov 16, 10:14 am, Ryan Davis <ryand-r...@zenspider.com> wrote:
> On Nov 15, 2007, at 23:20 , Markus Liedl wrote:
>
>
>
> > I have spent the last months to write an alternative Ruby grammar now
> > registered at rubyforge.org under the name "Ruby top down grammar".
>
> > The grammar is hosting language neutral. It must be interpreted or
> > translated to be run, i.e. to parse something. Currently there are two
> > translators, one to Emacs Lisp, the other to C. Both produce recursive
> > descent parsers.
>
> > The whole grammar is written in 270 rules taking 1500 lines. It
> > unifies lexical and syntactic analyses.
>
> > Another popular naming for such a grammar is Parsing Expression
> > Grammar. I extended some forms I found absolutely necessary. It's a
> > neutral and minimal but still practical grammar definition
> > language. The variation used here contains 31 different forms. The svn
> > repo contains a description of it.
>
> Dude... Congratulations! That is damn impressive!

thanks.

> I've tried, TWICE, to do an LR to LL flip on the ruby grammar (sans-
> PEG) and failed both times... My brain is just not that big. Using PEG
> definitely seems to be the way to go. We hung out and talked to the
> primary implementor of ometa at OOPSLA and are probably pushing in
> that direction over the medium to long term.

> Only now that I've got Parsetree's Uber Test Zuite(*) would I attempt
> such a task again, and hesitantly at that.

You'll write another parser? Explain that.

> I noticed a lot of elisp in your source tree... please tell me that
> you've hooked this up to ruby-mode! :P

Hmm. You are asking for too much. And there is also ruby-cedet.

For regular use within ruby-mode, one should be able to make this
parser incremental. Instead of calling rules you would manage
invocation and return yourself. Keep this stack in an array or
list. Every point where you might need to restart (every five lines,
or whatever) you clone the array or simply keep the list. There are
probably some issues with memoization; Do you need to keep the full
memoization table? Which entries can be deleted?
But in general I believe it is that simple.


> (*) PUTZ is not the most creative acronym... it could use some help.
>
>      Parse Tree Easy Werification Yay! = PTEWY!
>
>      I dunno...