[#1026] Is this a bug? — Dave Thomas <Dave@...>
18 messages
2000/01/03
[#1053] rand() / drand48() — ts <decoux@...>
11 messages
2000/01/05
[#1055] Re: rand() / drand48()
— matz@... (Yukihiro Matsumoto)
2000/01/05
[#1061] Re: rand() / drand48()
— gotoken@... (GOTO Kentaro)
2000/01/07
Hi,
[#1067] Here docs not skipping leading spaces — Dave Thomas <Dave@...>
5 messages
2000/01/08
[#1083] YADQ (Yet Another Dumb Question) — Dave Thomas <Dave@...>
12 messages
2000/01/10
[#1084] Infinite loop — Dave Thomas <Dave@...>
17 messages
2000/01/11
[#1104] The value of while... — Dave Thomas <Dave@...>
24 messages
2000/01/11
[#1114] Re: The value of while...
— Dave Thomas <Dave@...>
2000/01/12
matz@netlab.co.jp (Yukihiro Matsumoto) writes:
[#1128] Re: The value of while... — David Suarez de Lis <excalibor@...>
Hi all,
1 message
2000/01/12
[#1133] Re: Class variables... — David Suarez de Lis <excalibor@...>
Hi there,
2 messages
2000/01/12
[#1158] Is this expected behavior? — Dave Thomas <Dave@...>
6 messages
2000/01/21
[#1172] Re: Possible bug in ruby-man-1.4 — Huayin Wang <wang@...>
> |Well, I guess it comes down to what you mean by an integer
10 messages
2000/01/24
[#1177] Re: Possible bug in ruby-man-1.4
— Dave Thomas <Dave@...>
2000/01/25
matz@netlab.co.jp (Yukihiro Matsumoto) writes:
[#1188] Enumerable and index — Dave Thomas <Dave@...>
5 messages
2000/01/27
[#1193] Semantics of chomp/chop — Dave Thomas <Dave@...>
7 messages
2000/01/28
[#1197] Question about 'open' — Dave Thomas <Dave@...>
8 messages
2000/01/30
[ruby-talk:01179] Re: Possible bug in ruby-man-1.4
From:
Dave Thomas <Dave@...>
Date:
2000-01-25 06:05:49 UTC
List:
ruby-talk #1179
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