Thanks for the reply!
I guess what I'm getting at is that the Ruby parser makes a lot of
assumptions, when I write something like 1.class, the parser assumes I'm
calling a method on the Fixnum 1 rather than assuming I'm trying to make
some strange Float.
What you call "assumptions" is actually "precedence". The syntax of the
language is defined as it is and "." (method invocation, not to be
confused with the decimal point) has higher precedence than the range
operator "..". This really makes sense, for example:
for i in s.min..s.max
puts i
end
And when I type 3.14.class the parser is again smart
enough to figure things out, but this behavior is not carried over to
range. I know it's a design choice, and that range needs to be able to
hold more than just numerics, but since a statement like "range 1..'d'"
is meaningless, it seems like the proper behavior for range should be to
examine the first element of the range statement and then assume the
second element is of the same type (at least as far as parsing method
calls goes) then we would have (x..y).class == x..y.class which seems
like it would be more in line with other basic data types...
It cannot work that way because of the way parsers work: first the lexer
recognizes tokens. This is where it needs to decide that "1.23" is a
float literal and "1.23.class" is actually three literals ("1.23", ".",
"class"). Only after that phase that parser builds up the parse tree
which also establishes precedence. Your suggestion basically requires
to define different productions in the syntax for ranges with integer
literals and for ranges with other expressions to the left and right of
"..". I am not sure whether this is actually possible but there is a
certain risk that the syntax will not be conflict free and in any way it
means making the beast even more complex than it is today. Given the
limited usability and the easy workaround I'd say that cost estimates
rule against this change.
Of course, in typing this out, I see why it's set up the way it is,
since we might want to do something like this...
class SomeObj
def lastOne()
17
end
end
blah = SomeObj::new
a = 1..blah.lastOne
Exactly, arbitrary expressions are allowed on both sides of the "..".
Note also, that in this case the type of expression is actually unknown
at parse time.
Thanks for setting me on the path! (and letting me babble on...)
Cheers
robert
