[grammarians] [Rubygrammar-grammarians] Ruby Grammar Project

[Mauricio Fernández]

On Sat, Nov 26, 2005 at 11:54:03AM -0800, Terence Parr wrote:
> Ah.  So the AST construction treats referenced values as method  
> calls?  Interesting.  So the AST construction routine has to have  
> flow analysis to see if something is defined on the path of that  
> execution?  That doesn't sound like a very easy approach.  Imagine

No such analysis is needed, see below.

> if ...
> 	zort=3
> end
> blah = zort
> 
> In this case, which tree do you generate?  The flow analysis is the  
> only thing that can answer that...something usually WAY further down  
> the compilation pipe.

Ruby resolves it statically at parse time: 

if false
  zort = 3
end

blah = zort  # => NODE_LASGN(ID:blah, NODE_LVAR(zort))

Whenever the parser sees   foo = ...., it treats foo from that point on as a
local.

def foo; "method" end
a = foo                # => "method"
if false; foo = 1 end 
b = foo                # => nil

In the second case, the foo lvar is uninitialized.

> Well, I'm going to build a grammar.  If people want to use it for  
> doing Ruby tools like refactoring engines, cool.  If people need it  
> to replace the front-end of the Ruby interpreter, seems like there is  
> much more involved than just a grammar with AST construction.   
> 'course you'd start with a grammar and add actions...

Great news :)

[I was going to write this in a separate msg -> ]

As I see it, we need substantially different ASTs for the two major use cases
* code tools (analysis, refactoring...)
* interpretation

The current AST, which is walked by a recursive eval function
afterwards, is very interpretation-oriented: several node types have
been introduced incrementally in order to change the language, fix bugs,
etc. without altering (too much) eval.c. Also, the canonical nodes
change all the time, so nothing can depend on them... I've often thought
when reading parse.y that a refactoring tool would use a different AST.
Does anybody share that feeling?

So I was going to ask... what's the official goal of this project? Replacing
the current YACC parser + handmade lexer (seems so based on the initial msgs
about comparing the produced ASTs with the canonical ones) or creating the
basis for refactoring etc. tools? Or will there be two sets of actions to
produce two different ASTs?

-- 
Mauricio Fernandez