From: Markus <markus@...>
Date: 2004-10-12T23:42:40+09:00
Subject: Re: Ruby Directions (was Re: quality of error messages)

On Tue, 2004-10-12 at 01:37, Randy W. Sims wrote:
> Markus wrote:
> >>PS: I still like the other idea (end [(module|class|def) [<NAME>]]) 
> >>better. =)
> > 
> > 
> >      I have not been able to assure myself that this could be done
> > without breaking anything (or at least, be done by me).  I can see how
> > to do it, but I am just rusty enough on the guts of LR(1)/LALR(1)
> > parsers to be uneasy with the potential for conflicts.
> > 
> >      Would you like me to pursue the idea?  (With the caveat that my
> > experiments are for our enlightenment, and not meant to be
> > shaping/forcing ruby's development in any way that it does not wish to
> > go.)
> 
> Yeah. I'm toying around, taking a brief look at parse.y. I know a lot of 
> the theory of lexing/parsing. I've hand crafted small itsy-bitsy toy 
> lexer/parsers. But I'm mostly ignorant of what I'm looking at here.
> 
> I was thinking, focusing soley on class defs for the moment, that at the 
> start of a class definition it should be possible to store the class 
> name (cname?). Then at the close accept a optional 'class' keyword 
> following end, and then an optional identifier which must match the 
> stored cname. But I have no idea how to implement that at the moment.
> 
> I guess I should be reading the bison manual...

     I realized in my sleep (yes, I literally do program in my sleep)
that the reason I wasn't able to prove from the grammar that the
original for of this feature would not conflict was that the assumption
was false.  It would conflict.  Specifically (from my dream, but
identifiers changed to protect my subconscious):

    class Flork
        def self.blork
            #computation to return true 
            #if and only if subclass needs
            #to respond to :blork
            end
        end
    
    class Florkette << Flork
        def blork
            #code to blork a Florkette
            end if 
               blork
        end

is legitimate code that directly conflicts with the proposed syntax. 
There are several ways to do this.

     You could (as was proposed later on the thread) restrict the
tagging to named entities, but I haven't been able to work out that that
is conflict free either. 

-- Markus

P.S. "info Bison" has some GNU-clear examples.  You don't need to retain
too much external information, since the parse tree of a reasonable
grammar will have most of the parse tree nodes available near where you
need them.

Specifically, you can find the name of a class or function in the
grammar rule (probably something like $2.id) (IIRC, YMMV).