--00151750eae43653d404942765bc
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 3, 2010 at 5:45 AM, Ehsanul Hoque <ehsanul_g3 / hotmail.com>wrote:

>
> That makes sense. But the inconsistency between the different behaviors
> given just a small difference in whitespace is still quite off-putting.
>
> Also how is this line parsed?:
>
> x.slice(1, x.size -2)
>
> - It seems unreasonable to parse it any way other than that intended.Insert
> mode
>

Subject to correction by Robert - or anyone else! - to summarise I think the
basic problem for Ruby here is when to parse "-2" (without any space between
the "-" and the "2") as a unary operator on 2 and as a binary operator on a
previous "token" with 2 as the argument.

At one extreme, Ruby could raise an error if there is any possible
ambiguity. Ruby, I think, tries to do the best it can with *limited*
knowledge of the methods being interpreted.

For example:
  7 -2 5
this works for a similar reason to the reason this works:
  x  3
  x -2 #11
Ruby knows (or anyway interprets) x as a variable, not a method, so no
ambiguity: the "-" is either a mistake or is a binary operator.

  x.size #4
  x.size-3 #1
I'm guessing that here Ruby "thinks" no whitespace, so bind the "-" to the
first possible token, which is (x.size), so "-" gets treated as a binary
operator.

But in:
  x.size -2
this could mean
((x.size) - 2) or (x.size( -2 ))
In this case size doesn't take any arguments, so with some more work the
interpreter could parse it as being likely to be ((x.size)-2), but that
won't work for methods which can take zero or one (or more) arguments.
So (again a guess) the idea is that the interpreter won't even try to to
some extra work which might, or might not, resolve the ambiguity.

The result is what seems to me to be a reasonable compromise, but I ought to
add that some other possibilities might also be a reasonable (but different)
compromise!

--00151750eae43653d404942765bc--