Re: Dispatching, Multimethods and the like
At 10:37 AM -0400 6/17/03, Adam Turoff wrote: On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote: For methods, each object is ultimately responsible for deciding what to do when a method is called. Since objects generally share a class-wide vtable, the classes are mostly responsible for dispatch. The dispatch method can, if it wants, do *anything*. Hm. Ruby has unbound methods and per-object method binding. How does that impact Parrot's built-in dispatching behavior(s)? Unbound methods are just functions, and per-object methods create a transparent subclass for just the object being overridden. (Which is how Ruby does it, FWIW) > Core engine support will be in for this, since we don't want everyone to have to bother writing code for it all. Duplicate code. Bleah. We'll also provide method caches so we have some hope of not being horribly slow. Hm. Maybe the solution here isn't to fob off *all* dispatching to the core or the program, but have loadable dispatching behaviors, much like loadable datatypes and opcodes... Right. Hence the points of abstraction--so there's a well-defined place to take control, along with a well documented, if not actually sane, default. There's a lot you can do with sub/method wrapping as well, which there's language support for in perl 6. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dispatching, Multimethods and the like
On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote: > For methods, each object is ultimately responsible for deciding what to > do when a method is called. Since objects generally share a class-wide > vtable, the classes are mostly responsible for dispatch. The dispatch > method can, if it wants, do *anything*. Hm. Ruby has unbound methods and per-object method binding. How does that impact Parrot's built-in dispatching behavior(s)? > Core engine support will be in for this, since we don't want everyone to > have to bother writing code for it all. Duplicate code. Bleah. We'll > also provide method caches so we have some hope of not being horribly > slow. Hm. Maybe the solution here isn't to fob off *all* dispatching to the core or the program, but have loadable dispatching behaviors, much like loadable datatypes and opcodes... Don't know how desirable or implementable that idea would be. Or even if it's just half-baked. But it would be interesting to play around with things like a dispatcher that adds before: and after: methods (for AOP), or support for programming by contract sanity checking. Worst case, a Perl programmer might have to drop a pasm block in a class definition to link the dirty bits together without necessarily extending the language. Whatever happens, it's certainly one of those grey areas that lies smack between language definition and runtime implementation... Z.
Re: Dispatching, Multimethods and the like
On Tue, Jun 17, 2003 at 09:44:52AM -0400, Piers Cawley wrote: > Adam Turoff <[EMAIL PROTECTED]> writes: > > As it *appears* today, regular dispatching and multimethod dispatching > > are going to be wired into the langauge (as appropriate). Runtime > > dispatch behavior will continue to be supported, including things like > > AUTOLOADER and the like. > > Whoah! The wired in dispatch rules are going to be runtime dispatch > rules, but with potential compile time short circuiting where the > compiler knows enough stuff (frankly, I'm not sure I'd expect to see > compile time short circuiting in perl 6.0, maybe in 6.001 or whatever) That sounds about right. Perl as we know it is runtime dispatched, so adding compiletime short circuiting sounds like a job for a new pragma or declaration. 6.000+epsilon sounds like the right time to introduce this feature. Z.
Re: Dispatching, Multimethods and the like
Adam Turoff <[EMAIL PROTECTED]> writes:
> Damian just got finished his YAPC opening talk, and managed to allude
> to dispatching and autoloading.
>
> As it *appears* today, regular dispatching and multimethod dispatching
> are going to be wired into the langauge (as appropriate). Runtime
> dispatch behavior will continue to be supported, including things like
> AUTOLOADER and the like.
Whoah! The wired in dispatch rules are going to be runtime dispatch
rules, but with potential compile time short circuiting where the
compiler knows enough stuff (frankly, I'm not sure I'd expect to see
compile time short circuiting in perl 6.0, maybe in 6.001 or whatever)
> As of January, the thinking is sub DISPATCH {} will handle runtime
> dispatching behaviors, including autoloading, but easily accomodating
> value-based dispatching, AOP style pre/post methods, and whatnot.
>
> Unfortunately, Damian said that the design team isn't saying much about
> this, because the semantics aren't quite worked out yet, especially with
> the interaction between autoloading and other dynamic dispatching
> behaviors.
>
> Yes, this is a *big* issue.
Yeah, but it's a late binding one.
--
Piers
Re: Dispatching, Multimethods and the like
In <[EMAIL PROTECTED]> Adam Turoff wrote:
> Damian just got finished his YAPC opening talk, and managed to allude
> to dispatching and autoloading.
>
> As it *appears* today, regular dispatching and multimethod dispatching
> are going to be wired into the langauge (as appropriate). Runtime
> dispatch behavior will continue to be supported, including things like
> AUTOLOADER and the like.
>
> As of January, the thinking is sub DISPATCH {} will handle runtime
> dispatching behaviors, including autoloading, but easily accomodating
> value-based dispatching, AOP style pre/post methods, and whatnot.
>
> Unfortunately, Damian said that the design team isn't saying much
> about this, because the semantics aren't quite worked out yet,
> especially with the interaction between autoloading and other dynamic
> dispatching behaviors.
>
> Yes, this is a *big* issue.
It definitely is.
I can't speak for Perl 6 the language, but I can speak for Parrot, so I
can tell you what semantics will be available (though not necessarily
exposed) to the compiler.
For methods, each object is ultimately responsible for deciding what to
do when a method is called. Since objects generally share a class-wide
vtable, the classes are mostly responsible for dispatch. The dispatch
method can, if it wants, do *anything*. However, as some degree of
predictability is nice, the current plan is that classes will:
1) Look for the method in the class or parent. If found, it's
dispatched to. (This method may be defined as a multimethod in the class,
in which case MMD is used to determine which method of the set *in the
class only* is used)
2) Look for an AUTOLOAD method in the class or parent. If found, we
dispatch to it.
3) Look for a MMD version of the method outside of any class. If found,
do MMD
Core engine support will be in for this, since we don't want everyone to
have to bother writing code for it all. Duplicate code. Bleah. We'll
also provide method caches so we have some hope of not being horribly
slow.
By default, the system and class MMD will do class-based dispatching
only, deciding on which method to call based on the types of the
parameters. Both the class MMD method *and* the system MMD method may be
overridden if someone wants to install their own MMD scheme, though
overriding system-wide MMD stuff is always a dodgy thing. (Though no
more than any other overridden systemwide thing, I expect)
Will perl 6 support this? Dunno. Will it call for a different scheme? It
well might. Can a language completely skip the MMD stuff? It can if it
chooses, yes. What name will the dispatch sub be? Beats the heck out of
me, but then that's syntax and I don't do syntax. :)
