to_s precedence higher than -@ for Infinity ?

[trans. (T. Onoma)]

Is that right?

irb(main):001:0> i = 1.0/0
=> Infinity
irb(main):002:0> -i.to_s
NoMethodError: undefined method `-@' for "Infinity":String
from (irb):2

Doesn't do this for other numbers.

irb(main):004:0> -4.0.to_s
=> "-4.0"

T.

 

[Jamis Buck]

Is that right?

irb(main):001:0> i = 1.0/0
=> Infinity
irb(main):002:0> -i.to_s
NoMethodError: undefined method `-@' for "Infinity":String
from (irb):2

Doesn't do this for other numbers.

irb(main):004:0> -4.0.to_s
=> "-4.0"

No, but if you do:

a = 4.0
-a.to_s

You get the same error. When parsing numeric constants, the Ruby parser
includes '-' as part of the number. When '-' precedes a variable, it
uses the "-@" operator, which has a lower precendence than ".".

- Jamis

 

[trans. (T. Onoma)]

|
| a = 4.0
| -a.to_s
|
| You get the same error. When parsing numeric constants, the Ruby parser
| includes '-' as part of the number. When '-' precedes a variable, it
| uses the "-@" operator, which has a lower precendence than ".".

Thanks, Jamis

I see. I'm a little surprised that's intended. I understand the precedence of
"." being before the "!" operator, but I would think it would occur right
after "-" and "+" unary operators, user-defined or not. (Maybe "~" too.)

That's part of the niftiness of what I was offering Markus about his
user-defined operators. One could expect them to have a precedence corollary
to Ruby's built-in operators.

Thanks again,
T.

 

[Jamis Buck]

|
| a = 4.0
| -a.to_s
|
| You get the same error. When parsing numeric constants, the Ruby parser
| includes '-' as part of the number. When '-' precedes a variable, it
| uses the "-@" operator, which has a lower precendence than ".".

Thanks, Jamis

I see. I'm a little surprised that's intended. I understand the precedence of
"." being before the "!" operator, but I would think it would occur right
after "-" and "+" unary operators, user-defined or not. (Maybe "~" too.)

Consider this case, then:

a = "1.0"
-a.to_i

What precedence would you expect the '-' to have in this case? I think
this would actually be more common than "-a.to_s", too.

Still, POLS is in the eye of the beholder.

That's part of the niftiness of what I was offering Markus about his
user-defined operators. One could expect them to have a precedence corollary
to Ruby's built-in operators.

True. Though if you are suggesting that people be allowed to change the
precedence of existing operators..._that_ might start making me a little
uncomfortable. If you change the precedence of an operator, it can
change the result of an entire expression, resulting in code breakage,
and making it really hard for people to understand what an expression is
supposed to be doing.

But that's getting us off into the other discussion, which I'd really
rather not reignite...

- Jamis

 

[Markus]

True. Though if you are suggesting that people be allowed to change the
precedence of existing operators..._that_ might start making me a little
uncomfortable. If you change the precedence of an operator, it can
change the result of an entire expression, resulting in code breakage,
and making it really hard for people to understand what an expression is
supposed to be doing.

Agreed. I can't see any way that precedence could be changed by
the users without horrible complexities arising. That isn't to say that
someone brighter than I am might not come up with a clever
conceptualization, but everything I've thought of for dynamic precedence
(and associativity) would be so far from POLS to qualify as POMS.
(principle of mayonnaise surprise).

-- Markus