Dan Sugalski wrote:

[... massive sniping snippage ...]

> The problem I was talking about was those cases where we have a good but
> not perfect match at compile time. In the case you gave, we assume that @A
> are full of fish, so dispatch to the "multiple fish parameter" version of
> list_medication. But we can't be sure, since what happens if at runtime we
> install a list_medication function that takes an Aquarium array as a single
> parameter? (And we won't deal with the case where the function is there at
> compile time but deleted before we hit it)
> 
> We can do exact matching at compile time, but nothing else. "Best
> superclass" matching can't be done at compile time, since we can't be sure
> that something better won't come along later.
> 
>                                         Dan

what if:

        *>  there is a way to say that no new classes will be introduced

        *>  parameters have some additional flags, either as more elements
            of structure that ref() returns or as a second parallel array
            of lexical knowledge

        *>  dispatch functions have rights to rewrite themselves

The second one is really what I meant about a "more complex interface"
If we know that the second element is always going to be a puppy, the
dispatcher can be just a little bit simpler because it does not need
to consider the second element at run time.

At an op level, if function calls are all the same size, a function call
to a general dispatcher that knows the address of the function that called
it, and any other information could replace the call to itself with a call
to an arbitrarily simpler dispatch routine -- perhaps even a generic
dynamic dispatcher that knows it can't optimize any so it optimizes away
the pass to check for optimizability. 

In perlperl (imagine...) , that means turning a call foo($A) into

        &{$Dispatcher[macro_increment(N)] ||= sub {
                 goto &Dispatch_Default(macro(N),foo,$A)
        }} 

assuming that macro_increment will increment every time it is seen in the
source code -- that would be easy to do with a source filter :)

then Dispatch_Default could replace $Dispatcher[N] with a more specific
call,
to a simpler dispatcher or an alternate dispatcher or, in the rare and
elegant
case where we actually have all the type information ahead of time,
directly
to the function.



 
> --------------------------------------"it's like this"-------------------
> Dan Sugalski                          even samurai
> [EMAIL PROTECTED]                         have teddy bears and even
>                                       teddy bears get drunk

-- 
                                           David Nicol 816.235.1187
Keep that Sugalski character away from my stuffed animals!

Reply via email to