At 10:17 AM -0700 7/10/02, John Porter wrote:
>Dan Sugalski wrote:
>> What we're
>> doing is assuming we don't know and letting the variables decide
>> whether they'll care. Perl's will, though other languages can decide
>> differently.
>
>Letting the variables decide?
>So, we take a poll of all the arguments, and ask each one
>which they think ought to be the receiver?
>That would be O(n^2) in the number of args.
Sort of. That's what the multimethod dispatch table does, though
lookup is O(n) since we precompute the dispatch table. We look for
the entry in the table based on the type of the left and right side.
Since we're conveniently assigning each type a number, it's just a
matter of looking those numbers up and indexing into the table.
>And what if (as for other languages) the variables don't care?
>Then do we do left-side-wins?
Yes.
What we're really doing is left-side-wins always. It's just that, in
the case of all the perl types, they then do a multimethod lookup for
the ultimate routine to execute.
> > > maybe a
>> > kind of "paper-scissors-rock" rulebase that orders types.
>> > (What C/C++ hard-codes as "type promotion".)
>>
>> Type promotion makes me more nervous than multimethod dispatch.
>> I think I'd rather not do that unless we really have to.
>
>But I'm not talking about actually doing type promotion; it's
>just a scheme to decide who gets to decide.
>In the example of int-vs-float, the rulebase (it's really just
>a DAG) decides that float wins. So a float.method gets an int
>argument; the int isn't promoted to a float.
Ah. In that case it's really a subset of multimethod dispatch, so it
all sort of works out.
> > > If no match is found in the rulebase for the 2 (n?) types
>> > involved, then we could fall back to left-side-wins.
>>
>> If we can't find a match, or if there are two equal-distance matches
>> with no clear winner, we throw an exception.
>
>You don't like the idea of falling back to left-side-wins?
Oh, I like it, but at that point we've already decided to do a MM
lookup, so there's really no going back.
> > > Btw, I think the "distance in type space" idea is pretty kewl...
>> > but the thought of actually using it in parrot gives me thewillies.
>
>What bothers me is this: the programmer needs to be able to predict
>what the machine is going to do with the code she gives it.
>And predicting how the machine is going to resolve the multimethod
>call could be, in any but trivial cases, far too difficult.
>Programmers will end up guessing -- or, even worse, not giving it
>a single thought -- and then we may as well be programming in PL/1.
>:-)
Yeah, this definitely true, and I've been told it's an issue when
there are multiple routines that are almost, but not quite, correct.
One place where we make it easier on ourselves at this level is
restricting the inheritance hierarchy. Since pretty much everything
inherits directly from default it's pretty simple to predict.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
