At 10:04 PM 8/8/00 -0400, Ken Fox wrote:
>Chaim Frenkel wrote:
> > >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> > DS> To do it generally opens a huge can of worms. Doing it in a limited
> number
> > DS> of cases (int->BigInt, float->BigRat, char->UTF8) is more
> reasonable, and
> > DS> we can certainly manage that.
> >
> > Why limited? Doesn't this problem effect all pairwise combinations of
> > operators?
>
>Yes, but it has to be limited because there are an infinite number of
>possible conversions between types. We either follow strict rules about
>which type gets to handle the operations, or we have flexible rules for
>a strict subset of the possible types.
Yup, that's pretty much it. Define the cases we do know, and drop a
fallback case for the rest.
>I think Dan is proposing that we have flexible rules, but if those fail
>then we fallback on the strict ones. Unfortunately, this may not be
>predictable for the user -- it's kind of a DWIM feature and those have a
>nasty habit of turning into surprises if the system can't figure out what
>you mean.
I understand that, but I also feel that given:
$foo = new BigInt 12e65;
$bar = 15;
these two ops:
$ans[0] = $foo * $bar;
$ans[1] = $bar * $foo;
should give the same answer. Perhaps a "promote to the biggest type" rule
for mathematical expressions or something.
Of course there's still the whole issue of overloaded operators. That opens
up a whole 'nother can of worms. But I consider that in a different class,
sort of, than perl's built-in data types.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
