Re: Yadda yadda yadda some more
On Fri, 2004-05-14 at 18:53, Luke Palmer wrote: > Aaron Sherman writes: > > or did Larry mention a way to define a converter and I missed it? > > Yep, that's what happened. See Apocalypse 12 under "Overloading." Ok, so in the case of: my int $i = ...; we should apply C and fail at run-time, correct? There's nothing wrong with TRYING to do the conversion, just as there should not be anything wrong with: my int $i = "4"; which has some pretty simple semantics in Perl. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Yadda yadda yadda some more
Aaron Sherman writes: > On Fri, 2004-05-14 at 18:53, Luke Palmer wrote: > > Aaron Sherman writes: > > > > or did Larry mention a way to define a converter and I missed it? > > > > Yep, that's what happened. See Apocalypse 12 under "Overloading." > > > Ok, so in the case of: > > my int $i = ...; > > we should apply C and fail at run-time, > correct? There's nothing wrong with TRYING to do the conversion, just as > there should not be anything wrong with: > > my int $i = "4"; > > which has some pretty simple semantics in Perl. Right. Though, constant folding at CHECK time might be able to tell when you're *going* to do an invalid conversion and complain about it right then. In the case of ..., give it type error semantics. That is, any expression involving ... gets type "...". Except instead of reporting at the end of the statement, just suppress the errors and move on. Luke
RFC eq and ==
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 patents are a threat to innovation in Europe please check: http://www.eurolinux.org/
Re: RFC eq and ==
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? 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 considering though. -- c
Re: RFC eq and ==
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" 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 considering though. > > -- c > 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. Regards. -- Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org Software patents are a threat to innovation in Europe please check: http://www.eurolinux.org/
Re: RFC eq and ==
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 stay. En mi humilde opiniÃn, the idea is not archaic, but quite
modern. Or postmodern Larry would say, though I don't really understand
what that means.
Since scalars are polymorphic, their operations must not be. The
problem is the same as that of using + for string concatenation (which
has been proposed far too many times). A big part of Perl is the
ability to do:
my $a = 43;
$a += 1;
$a ~= " bananas"; # 44 bananas
And the ability to keep the semantics the exact same if you happen to
put quotes around the "43"... or read it in from a file, for instance.
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
But it's been pointed out:
if +(some($big+%nastyÂexpressionÂ)) == +$b {...}
Now it takes three, maybe four re-scans to figure out that it's a
numeric comparison. Kills readability.
Fortunately for the generic programmer there's a generic equality which
returns true when objects are the same type (or almost the same, like an
integer and a string that looks like an integer), and false otherwise.
Larry called it "equal", though "equals" seems much, much better.
if $a equals $b {...}
There's your "polymorphic" equality, if you will. I'd be wary of using
it often, however.
Luke
Re: RFC eq and ==
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 you've used the data they hold. If you treat a scalar like a number, it'll behave like a number. There are some wacky corner cases, though, where you see side-effecty action at a distance. (I remember running across this at least twice, though I don't remember specific examples. DWIM usually works well.) 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? The solution for an API designer may be "be very careful, then!" but I'm not sure a language designer has that luxury. -- c
Re: RFC eq and ==
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 something else, but that's
different). In turn, I'd expect eq to have implicit stringifies.
Therefore I'd expect the +'s to redundant in the first example.
I'd then expect the second example to first convert $a and $b to strings
because of the ~'s, then, because it sees the ==, it would numify those
strings and do a numeric compare.
Are my expectations misaligned here?
-- Rod
Re: RFC eq and ==
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
> operands (unless user-overloaded to something else, but that's
> different). In turn, I'd expect eq to have implicit stringifies.
> Therefore I'd expect the +'s to redundant in the first example.
>
> I'd then expect the second example to first convert $a and $b to strings
> because of the ~'s, then, because it sees the ==, it would numify those
> strings and do a numeric compare.
>
> Are my expectations misaligned here?
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.
Luke
Re: RFC eq and ==
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 fast. I'd be seriously annoyed if eq went away. It's one of those things that makes Perl Perl. It's up there with the postfix if. ~$a == ~$b feels too much like: Cast(String, $a).Compare(Cast(String, $b)) -- Rod
Re: RFC eq and ==
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 attractive to me, because it's a bit like
lc $a eq lc $b
Juerd
RE: RFC eq and ==
> -Original Message- > From: Rod Adams [mailto:[EMAIL PROTECTED] > I'd be seriously annoyed if eq went away. It's one of > those things that makes Perl Perl. It's up there with > the postfix if. > > ~$a == ~$b > feels too much like: > Cast(String, $a).Compare(Cast(String, $b)) > But it's far easier to convert polymorphic == into an eq macro than to convert eq into an == macro. :-) =Austin
