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

On Fri, Sep 26, 2008 at 12:24 PM, Wincent Colaiuta <win / wincent.com> wrote:

> On 26 sep, 02:54, Clifford Heath <n... / spam.please.net> wrote:
> > Wincent Colaiuta wrote:
> >
> > > One of the things I always liked about the system was that you wrote
> > > your grammars in Ruby.
> >
> > I think that's an error, based on the presumption that "is Ruby, is
> good".
> > Not all that's Ruby is golden,,, err... red ;-).
>
> Well, using a Ruby DSL brought with it three advantages:
>
> 1. Could develop incrementally seeing as I already had a working
> interpreter (the Ruby interpreter); no need to develop a custom parser
> to parse the DSL. This allowed me to develop very very quickly with
> minimal time between "initial idea" and "first basic, working
> implementation".
>
> 2. Could leverage existing Ruby functionality to take shortcuts; for
> example, regular expressions were already just sitting there waiting
> to be used, or lambda blocks to create miniature "sub-parsers" and
> handle embedded langauges etc.
>
> 3. (Debatably) A shorter learning curve because I already know Ruby.
>
> None of these are show-stopping "deal-winners", but they were things
> that lead me down the DSL-in-Ruby path. That and the fact that there
> are so many DSLs written in Ruby out there that you find yourself
> using them all the time (to a person with a hammer, everything looks
> like a nail).
>
> On 26 sep, 04:30, Eric Mahurin <eric.mahu... / gmail.com> wrote:
> >
> > 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)
>
> Yes, although Pappy, written in Haskell and one of the first Packrat
> parsers (if not the first) does it using Higher Order functions. I do
> it using Ruby continuations.


If you mean parser combinator when you say "higher order function", I would
assume that many/most parser DSLs specified in a programming language use
parser combinators.  Mine does.  My first approach was to parse directly
when the DSL is "executed" and I assume that is what you are doing.  But,
instead you can make the DSL build a data structure (which might have user
specified blocks/lambdas in it).  You can then analyze and then parse.

> 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.
>


> Let's take regular expressions, for example. By using a Ruby DSL you
> can allow the user to specify something using a regular expression and
> you can suddenly recognize all those regular language structures
> basically "for free". But if you want to do static grammar analysis on
> something that uses Ruby regular expressions you either have to look
> inside the expressions at runtime (effectively writing yet another
> parser to break them down), or you have to forgo Ruby's and roll your
> own. This is because in order to do any kind of useful static analysis
> you have to be able to reduce the regular expression into a canonical
> DFA.


I think I see what you are saying.  I assume you are talking about the
"actions" primarily.  If you allow user actions to play a role in parsing
(not just AST generation), it would be an issue.  I suppose this could limit
some optimizations for mine (actions could make a grammar context sensitive
for example), but I haven't found it to be performance limiting.

If you use something like the rubynode library that can extract ruby parse
trees from lambdas (or any ruby in the current interpreter), you could
possibly do some analysis of even the actions.  But that probably isn't
worth the effort.

Eric

------art_16739_24918469.1222491381226--