From: Charles Comstock <cc1@...>
Date: 2004-03-02T02:34:49+09:00
Subject: Re: perl6 grammar rules in ruby

Ara.T.Howard wrote:

> 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

Well take for instance parsing some html, but while it is possible to 
parse the whole file with REXML (assuming it's valid xhtml, which is 
unlikely) or use ruby-htmltools which I guess tries to fix some 
html-isms that break rexml, but both require a switch in context.  If 
you had an embedded grammar, you could construct a regex to look for the 
region you wanted, and then construct a simple grammar to extract the 
meaningful data from there.  Yes you could technically write a grammar 
with racc, but that is more structured towards parsing the whole file. 
It's a question of programmar speed, and ease of use.  When you code in 
other languages which do not have regex embedded or, have regex objects 
that have a more cumbersome syntax, as a programmar I don't depend on 
them quite as much.  I'm slightly more likely to use index or substr or 
whatever which may be less suited to the task.  I do this because it is 
the easiest path in that language.  It feels easier even though in the 
long run it may not be.

Languages like awk and perl pushed forward this idea of embedded regex, 
which allowed the programmar to use that functionality without in 
essence switching contexts, letting regex become the easiest path.  If a 
grammar was equally available, if a grammar was the easiest path, then 
it would become as useful a tool as the regex.  I think it's hard to 
think of all the places it would be easier to use a grammar, because we 
aren't used to thinking that way as programmers.  Making powerful tools 
the path of least resistance can do nothing but benefit the programmer.

Charles Comstock