[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Subclassing Struct.new

MenTaLguY

3/1/2006 6:41:00 PM

Quoting Yukihiro Matsumoto <matz@ruby-lang.org>:

> |Will the Ruby2.0 grammar no longer have variable/method
> ambiguities?
>
> I'm not sure what you meant by "ambiguities". The identifiers
> not assigned in the scope will be treated as method calls, as
> well as in current behavior.

When speaking of grammar, "ambiguity" refers to situations where the
same text can parse to more than one tree -- for example:

foo[1] # (call (lvar foo) [] (array 1))
foo [1] # (call (lvar foo) [] (array 1))

versus:

foo[1] # (call (fcall foo (array)) [] (array 1))
foo [1] # (fcall foo (array (array 1)))

There may be disambiguating factors (e.g. whether 'foo' is known a
priori to be an lvar or a method), but those are external to the
grammar.

Rather than making the grammar itself ambiguous, it would be better
to introduce a new 'lvar-or-fcall' production parse the above
expressions unconditionally as:

foo[1] # (call (lvar-or-fcall foo) [] (array 1))
foo [1] # (fcall foo (array (array 1)))

This way, it would be possible to write an unambiguous context-free
grammar for Ruby (heredocs and so forth aside).

Also, it would help users confused about whether "foo [1]" parses as
a method call or a variable access, since "foo 1" always parses as a
method call.

You'd still be free to backpatch the lvar-or-fcall node to an lvar
or fcall if you wanted to do so, but it wouldn't complicate the
grammar any longer.

Please don't make Ruby even harder to parse...

-mental
1 Answer

MenTaLguY

3/1/2006 7:41:00 PM

0

Quoting Terence Parr <parrt@cs.usfca.edu>:

> Let me second the idea that whitespace should not change the
> meaning of a construct...bad enough that it's context-sensitive
> (and lexically not via flow analysis) so that foo can be a
> function call or var ref. ick.

I don't agree about whitespace in this case -- I think it's fine
that foo[1] and foo [1] parse differently to one another given that
Ruby otherwise uses whitespace to signal the start of an argument
list (and that too I think fine).

However, the context-sensitivity is a problem. Speaking of context,
I neglected to include some when I CCed the grammarians list.

What Matz is proposing for Ruby2.0 is that the criteria for a name
being treated as local variable would change from "assignment
appearing anywhere prior to the point in question" to "assignment
appearing anywhere within the same method/scope/etc".

So, rather than:

def foo
n # method
end

def hoge
n # method
n = 1
n # variable
end

We get:

def foo
n # method
end

def hoge
n # variable
n = 1
n # variable
end

I think that's a good idea -- at least, it would be if there weren't
ambiguities in the grammar that would consequently require multiple
passes or backpatching the AST to resolve.

So, just for to-day, I am putting on my prescriptivist hat. We'll
have to defer to Matz's ultimate decision, but I hope I can
persuade him to address the ambiguities for 2.0.

-mental