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

> You are right.  I'd like to hear your opinion about this.
> 
>   -13.remainder(4) => (-13).remainder(4) or -(13.remainder(4))
>   -foo.remainder(4) => (-foo).remainder(4) or -(foo.remainder(4))

Well, I guess it comes down to what you mean by an integer
literal. Right now, we have a somewhat confusing situation:

  a = -2

assigns '-2' directly to a

  a = -2.+(3)

generates  5:Fixnum, then applies -@, resulting in -5.

I think that breaks most people's expectations. When they see -99,
they think of the number '-99', not 99 negated. When they see -2.abs,
I think they'd expect to see 2, not -2.

So, I'd personally feel that it's more natural to do a lookahead on
MINUS for a digit, and if found, generate the negative number
directly. That way -2.+(3) would parse as (-2).+(3).

When it comes to -a.abs(), I think the argument is subtly different. I
suspect most people would look at that in any programming language and 
stop to think about precedence. They might bracket it to be safe. I
don't think they have too many ingrained expectations, the way we have 
with negative numbers. So, I could argue -a.abs() either way, and
leave it up to the language designer to tell me the precedence rules.

I think the goal is to have a language with the fewest number of
surprises--one that doesn't have built-in "gotchas". -2.abs is a
surprise to most people.

Regards


Dave


-- 
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++. 

Now in bookstores:
 The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/