matz / netlab.co.jp (Yukihiro Matsumoto) writes:

> |Maybe the answer is to get rid of the concept of negative numeric
> |literals, so there's never any ambiguity as to whether -2 is a literal 
> |of a method call? Then, as an optimization, the parser could notice
> |<Fixnum>.-@ terminal pairs and replace them with a negated
> |Fixnum.
> 
> That is the current behavior (without optimization). 

Is that true, though?  1 + -2 seems to invoke 1.+, passing in negative 
2, without invoking 2.-@. The code in parse.y does:

  | tUMINUS arg
    {
	if ($2 && nd_type($2) == NODE_LIT && FIXNUM_P($2->nd_lit)) {
	    long i = FIX2LONG($2->nd_lit);
	    $2->nd_lit = INT2FIX(-i);
	    $$ = $2;
	}
	else {
	    $$ = call_op($2, tUMINUS, 0, 0);
        }

So 'tUMINUS Fixnum' will always be reduced to a negative Fixnum. I was 
suggesting that optimization could be deferred until the tree is
built, and you know that the Fixnum is a terminal. That way, you'd
convert the '2' in '1 + -2', but not the '2' in -2.abs.


> The problem is about the contradiction below.
>                                                    current modified
>   -13.remainder(4) => better be (-13).remainder(4)   yes      no
>   -2**2            => better be -(2**2)              no       yes
> 
> There may be good syntax rules to solve this.

Should "-2 op 2" always evaluate to the same as "-2.op(2)"? If not,
then what's the effect of bumping the precedence of method application 
down below unary minus? (This strikes me as a frightening change ;-)

Dave