Re: RFC eq and ==

2004-05-18 Thread Simon Cozens
[EMAIL PROTECTED] (Chromatic) writes: Is 10 a string? Is it a number? Is 10base-T a string? Is it a number? Is an object with overloaded stringification and numification a number? Is it a string? I don't know a good heuristic for solving these problems. If you have one, it's worth

Re: RFC eq and ==

2004-05-18 Thread Aaron Sherman
On Mon, 2004-05-17 at 17:13, chromatic wrote: As Luke suggests, there's also programmer clarity to consider. If determining how to compare depends on how you've used the variables to compare, is it harder to understand the code? To be specific, what does: my $a = foo(); my

RFC eq and ==

2004-05-17 Thread Pedro Larroy
Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? Or the will is to keep eq, gt and the others. (not very nice emho). Regards. -- Pedro Larroy Tovar | Linux Network consultant | piotr%member.fsf.org Software

Re: RFC eq and ==

2004-05-17 Thread chromatic
On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? How does the compiler know which is which? Is 10 a string? Is it a number? Is 10base-T a string? Is it a number?

Re: RFC eq and ==

2004-05-17 Thread Pedro Larroy
On Mon, May 17, 2004 at 01:42:26PM -0700, chromatic wrote: On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? How does the compiler know which is which? Is 10

Re: RFC eq and ==

2004-05-17 Thread Luke Palmer
Pedro Larroy writes: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? Or the will is to keep eq, gt and the others. (not very nice emho). It was decided long ago that the distinction between == and eq is going to

Re: RFC eq and ==

2004-05-17 Thread chromatic
On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote: I thought perl internally would know. At least in perl5 it has to know somehow, since you can $var++ when is numeric and also when it's a string, and behaves different in each case. True. Perl 5 scalars do keep track of the context in which

Re: RFC eq and ==

2004-05-17 Thread Rod Adams
Luke Palmer wrote: Admittedly, if you use == for everything, you can force string or numeric comparison this way: if +$a == +$b {...} # numeric if ~$a == ~$b {...} # string Hmm. In my head, I would expect == to have implicit numification on the operands (unless user-overloaded to

Re: RFC eq and ==

2004-05-17 Thread Luke Palmer
Rod Adams writes: Luke Palmer wrote: Admittedly, if you use == for everything, you can force string or numeric comparison this way: if +$a == +$b {...} # numeric if ~$a == ~$b {...} # string Hmm. In my head, I would expect == to have implicit numification on the

Re: RFC eq and ==

2004-05-17 Thread Rod Adams
Luke Palmer wrote: Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a polymorphic operator. You're correct in terms of the current (and hopefully continuing) state of things. Went back and re-read your first post, and that is indeed what you were saying, I just read it too

Re: RFC eq and ==

2004-05-17 Thread Juerd
Luke Palmer skribis 2004-05-17 14:54 (-0600): Admittedly, if you use == for everything, you can force string or numeric comparison this way: if +$a == +$b {...} # numeric if ~$a == ~$b {...} # string And $a :=: $b could be written as \$a == \$b. Oh, hm. It does sound kind of