------art_8697_13336726.1222396249409
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Sep 24, 2008 at 3:49 AM, Wincent Colaiuta <win / wincent.com> wrote:

> But I think both of those options would require me to lose the Ruby
> DSL and switch to a custom, non-Ruby language for specifying grammars.
> One of the things I always liked about the system was that you wrote
> your grammars in Ruby. Evidently, you can only do static analysis once
> you've parsed the grammar, and that would be fiendishly difficult (or
> impossible?) to do with a dynamically-constructed one built on the fly
> by evaluating the Ruby DSL.
>

Hi Wincent,

Just because you are using a Ruby DSL, you shouldn't be limited.  There is
nothing that says your DSL couldn't build exactly the same data structures
that you'd build if you read/parsed in a non-Ruby DSL.  In my Grammar
project, I create a Grammar tree with a Ruby DSL (simply methods that create
and combine Grammars).  I can parse directly using this tree or I can
generate highly optimized code.  Here are a few optimizations: flattening
(method calls only needed for recursion), tail call optimization (right
recursion), left recursion (normally unheard of with LL), some refactoring,
and boolean minimizations.  The main thing that should matter in terms of
analysis should be your data structures, not how you get there.  A ruby DSL
will only enhance flexibility.

Eric

------art_8697_13336726.1222396249409--