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.
trans. (T. Onoma) wrote:
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):2Doesn'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
···
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis
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.
···
On Sunday 10 October 2004 11:28 pm, Jamis Buck wrote:
No, but if you do:
a = 4.0
-a.to_sYou 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 ".".
trans. (T. Onoma) wrote:
> 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 ".".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
···
On Sunday 10 October 2004 11:28 pm, Jamis Buck wrote:
--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis
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
···
On Sun, 2004-10-10 at 21:28, Jamis Buck wrote:
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.