Robert Feldt wrote:

> anon luker wrote:
> 
>> "Ara.T.Howard" <ahoward / fattire.ngdc.noaa.gov> wrote in message 
>> news:<Pine.LNX.4.44.0403010952220.2865-100000 / fattire.ngdc.noaa.gov>...
>>  
>>
>>> On Mon, 1 Mar 2004, Charles Comstock wrote:
>>>
>>> <snip>
>>>   
>>>
>>>>  Here we run into a bunch of problems with translation.  I will start
>>>>  thinking of a nice way to embed this in the ruby syntax, as I don't 
>>>> really
>>>>  think that much of the Perl style syntax.  While the inheritence 
>>>> portion MAY be possible to implement in the current ruby syntax, 
>>>> other parts
>>>> would definitely need a custom regex engine, which probably 
>>>> sacrifices speed
>>>> amoung other things.
>>>>     
>>>
>>> sound like an o.k. idea, but what advantage would it have over racc, 
>>> which is
>>> already distributed with ruby?  i must say the value of dynamically 
>>> creating
>>> parsers seems like it would not be too heavily used - just making a good
>>> parser is hard enough and i would think that any grammars simple 
>>> enough to
>>> generate parsers for on the fly would be simply enough to parse by hand.
>>> considering that, i perfer the approach of racc which will generate a 
>>> static
>>> parser using a very ruby-esc syntax.
>>>
>>> -a
>>>   
>>
>>
>> FWIW, I am having a love affair w/ boost::spirit.  I use it _all_ the
>> time.  Planning a proper grammar for even trivial things like
>> command-line arguments and then concisely parsing them w/ spirit gives
>> me a warm fuzzy feeling.  I would never ever ever use the traditional
>> parser generators (or their clones) for such tasks, though (nevermind
>> that I prefer writing right-recursive grammars).  Spirit's style is
>> very much tied to the language for which it was written, but I still
>> think that it is a good role-model.
>>
>>  
>>
> Is the importance the integration with the language or the fact that you 
> can create parsers dynamically? I'm aiming for the latter with Ruby but 
> the grammars can either be written in a string (in the Rockit grammar 
> format) or constructed directly with the Grammar classes. I haven't 
> checked out the Perl6 stuff but my impression is that the the original 
> poster thinks the integration into the host language is the most 
> important thing. Can someone clarify?
> 
> /Robert
> 
> 
> 
> 
The advantage of the embedded system is you can call out to a grammar 
inline from a builtin regex, something you can't really do in ruby at 
the moment.  Basically with the perl6 grammars you would be able to say
text =~ /__START__<ruby>__END__/ where ruby would be the grammar for 
ruby with associated callbacks for each grammar node to say create an 
AST.  The fact it can be embedded in a regex gives the nice touch that
a) you can switch quickly back and forth between the grammar and lexer level
b) it just makes it alot easier to use a grammar from within the language.

It might help the discussion if a few more people take a look at how the 
grammars are designed to work in perl6.  If the functionality they are 
trying is possible without extending the language then go for it, but I 
am inclined to believe it is not possible without a seperate regex 
engine at the moment.  In addition the ability to inherit grammars would 
probably be easier if it was embedded in the language, but it is 
certainly possible to work around that constraint.

The pertinent perl6 grammar references:
http://dev.perl.org/perl6/exegesis/E05.html
http://dev.perl.org/perl6/apocalypse/A05.html

Charles Comstock