Re: Multimethod Dispatch
At 5:41 PM -0700 9/3/02, David Wheeler wrote:
>On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
>
>>We call that concept "multimethod dispatch". That's what you're asking for.
>
>Dan, can you explain what "multimethod dispatch" is?
Damian can explain it better than I can, but it's essentially when
you dispatch based on sub or method signature. You're allowed to have
multiple versions of a single sub as long as they differ in their
parameter signature.
So you could have a
sub xyzzy(Foo $a) {
print "Foo!\n";
}
as well as a:
sub xyzzy(Bar $a) {
print "Bar!\n";
}
And at runtime when you call xyzzy, the system looks at your
parameter to decide which to call. Inheritance trees are searched as
well, so if you had a Baz, which ISA Bar, calling xyzzy with a Baz
would print out "Bar!"
Things get... interesting with multiple inheritance, and multiple
parameters, but the general solution to potential conflicts, where
there are two or more equally "right" things is to either use a
default or throw an exception.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Multimethod Dispatch
On Tuesday, September 3, 2002, at 06:12 PM, Dan Sugalski wrote: > Damian can explain it better than I can, but it's essentially when you > dispatch based on sub or method signature. You're allowed to have > multiple versions of a single sub as long as they differ in their > parameter signature. Ah, yes, the same thing exists in Java. I remember, now. Thanks Dan, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Multimethod Dispatch
David Wheeler wrote: > Ah, yes, the same thing exists in Java. I remember, now. I thought Java only has over loading? Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. - Ken
Re: Multimethod Dispatch
From: Ken Fox [EMAIL PROTECTED] > Over loading is what C++ has. It is not the same as > multi-dispatch. The trouble with over loading is that the > compiler uses static (compile-time) type information to > select the over loaded method. This can create subtle > bugs when people try to re-use code by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Multimethod Dispatch
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: > >From: Ken Fox [EMAIL PROTECTED] >> Over loading is what C++ has. It is not the same as >> multi-dispatch. The trouble with over loading is that the >> compiler uses static (compile-time) type information to >> select the over loaded method. This can create subtle >> bugs when people try to re-use code by sub-classing. > >So, just to clarify, does that mean that multi-dispatch is (by definition) >a run-time thing, and overloading is (by def) a compile time thing? No. They can be both compile time things or runtime things, depending on the characteristics of the language. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: > No. They can be both compile time things or runtime things, depending > on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? And will Perl 6 do it at compile-time or at run-time? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Multimethod Dispatch
At 7:31 AM -0700 9/4/02, David Wheeler wrote: >On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: > >>No. They can be both compile time things or runtime things, >>depending on the characteristics of the language. > >So if it's compile-time for a given language, how is it different >from the Java concept of overloading? It probably isn't, though I'm unfamiliar enough with Java to say for sure. >And will Perl 6 do it at compile-time or at run-time? Runtime. There's no way we could do it at compile-time--too much uncertainty. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
Just some thoughts (and an idea):
I have found the whole context thing in Perl5 easier to understand when I regard it as
overloading based on the return type. We all know that languages like C, C++ and Java
throw a compile-time error if two function
definitions differ in their return type only. Perl does something close to return type
overloading with many of its builtin functions. At least, that's the impression you
get from the outside (and I have never looked inside, so
excuse my lack of knowledge about the Perl5 internals ;-) )
Now my suggestion: Couldn't context sensivity in Perl6 be implemented by extending
multi-method dispatch to include return types? That could be generalized and would
allow things like:
my PNG $png = PNG.new("images/img0001.png");
my JPEG $jpeg = $png.convert();
my GIF $gif = $png.convert();
Of course you could have convertToJPEG() and convertToPNG(), but that's the whole
point of overloading and multimethod dispatch, isn't it?
The usual list context / scalar context distinction would of course still be possible.
It's just about _extending_ context sensivity.
[Comments | Suggestions | Criticism] welcome.
Re: Multimethod Dispatch
The specific definitions of these terms vary from language to language. In Java, for instance, a method is said to be "overloaded" and/or "overridden". An "overloaded" method is actually two or more methods with the same name but differing numbers/types of parameters (which Java calls the "signature" of the method). I believe this is what has been referred to as "multimethod dispatch" on this thread. An "overridden" method is two methods with the same name AND type signature in two different classes, where one class is a subclass of the other. The child class's method is said to "override" the parent class's implementation. The similarity of names is a little confusing, but the distinction between the two mechanisms is important. When an overridden method is called, the actual implementation that gets executed depends on the RUNTIME type of the INVOCANT. When an overloaded method is called, the implementation that is executed depends on the COMPILE-TIME type of the PARAMETERS. Many folks get bitten trying to use overloaded methods as if the implementation were chosen based on on run-time type information. But that's all off-topic. Back to Perl6, although it seems that we won't find out the details of Perl6 O-O until Apoc 12 comes out. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- grasshopotomaus: A creature that can leap to tremendous heights . . . once.
Re: Multimethod Dispatch
Dan Sugalski wrote: >> Dan, can you explain what "multimethod dispatch" is? > > Damian can explain it better than I can, I thought you did a great job! However, anyone who wants to know more about multiple dispatch might also like to read: http://www.samag.com/documents/s=1274/sam05010010/ Damian
Re: Multimethod Dispatch
Dan Sugalski wrote: > At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: >> So, just to clarify, does that mean that multi-dispatch is (by >> definition) >> a run-time thing, and overloading is (by def) a compile time thing? > > No. They can be both compile time things or runtime things, depending on > the characteristics of the language. I don't think so. Those terms are well understood by the OO community. Bertrand Meyer wrote on the subject: http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf Prior to C++ there might have been some ambiguity (for example, some people have talked about run-time vs compile-time overloading), but C++ has completely stolen the term. Here's a slide from one of Damian's presentations that states multi-methods are "Like C++ overloading, but polymorphic." http://www.csse.monash.edu.au/~damian/TPC/1999/MultipleDispatch/Presentation/sld010.htm - Ken
Re: Multimethod Dispatch
At 9:27 PM -0400 9/4/02, Ken Fox wrote: >Dan Sugalski wrote: >>At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: >>>So, just to clarify, does that mean that multi-dispatch is (by definition) >>>a run-time thing, and overloading is (by def) a compile time thing? >> >>No. They can be both compile time things or runtime things, >>depending on the characteristics of the language. > >I don't think so. Those terms are well understood by the OO community. >Bertrand Meyer wrote on the subject: >http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf Yeah, but what he wrote was "don't do that, in any of its forms." While an interesting argument, it's a touch late for perl. >Prior to C++ there might have been some ambiguity (for example, some >people have talked about run-time vs compile-time overloading), but >C++ has completely stolen the term. Here's a slide from one of Damian's >presentations that states multi-methods are "Like C++ overloading, >but polymorphic." >http://www.csse.monash.edu.au/~damian/TPC/1999/MultipleDispatch/Presentation/sld010.htm Hrm. I generally use "overloading" in the "operator overloading" sense, which is where the confusion comes in, I expect. Operator overloading can be a compile or runtime thing, depending on your preferences. Figuring out what function/method to call based on parameters and return types can also be a runtime or compile time thing, once again depending on preferences. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod dispatch?
> Apologies if I've missed some earlier discussions on multimethods. The > apocolypses, exegesises and synopses don't seem to say much other than > (a) they will exist and (b) wait for apocolypse 12 for more information. > > Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the > intent is to implement method overloading similar to C++/Java or > multimethods in CLOS in a Perlish fashion. Dan's WTHI MMD[***] has also > been quite helpful. > > I'm paging through "The Art of the Metaobject Protocol" for bedtime reading > material, and multimethods are starting to give me a big case of The Fear. > > > As I understand it, the idea behind MMD is that languages like C already > do it with basic operators, since '5 + 3' generates different instructions > than '5 + 3.1' or '5.5 + 3.1' do. But weak languages like C do not allow > that mechanism to be triggered by user defined functions. The obvious > answer in type heavy languages like C++, Java or Common Lisp is to extend > that behavior for user defined functions. That's called "overloading". It's compile-time. MMD usually refers to run-time semantics, but in Perl it refers to both. > Somehow that just feels wrong in Perl. In all of the Perl code I've > written, I've *never* felt the need to overload the + operator, or have > one of five possible implementations of new() automagically selected by > the datatypes of its arguments. Furthermore, most Perl programs I've read > or written aren't very type heavy -- there's still a lot of text slinging > and plain vanilla reference processing going on, and presumably that will > still be the case in five years' time. You must not be following Perl 6 closely enough, then. Perl 6 is a "real" programming language now, as opposed to a "scripting" language. It will still have a lot of power in text processing, and still be a powerful "quicky" language, but that's no longer its primary focus -- not to say that highly structured programming is. Some applications want strong typing, some don't. That's why typing is optional (which is still driving me nuts as to how that's going to work). > Type-based MMD as it exists elsewhere are solving a problem that does not > exist in Perl, or at least does not exist to the same extent it does in > other languages. Similarly, value-based dispatching is dirt simple in > Perl and easy to implement that it's an idiom that at least I use > constantly. And you can still do it the Perl 5 way in Perl 6. We're just taking common idioms and adding them into the language so not as much typing is required. And also adding the always-useful procedural-to-declarative transformation. > Add all that up, and MMD is a lot of pain for not a huge benefit. Not > because MMD is a necessarily bad idea, but because MMD doesn't go *far* > enough, since it's limited to type signatures. Well, type signatures are the only relevant information we have, so that's what we'll use. See below. > A better fitting solution wouldn't focus on classic MMD, but simply > "Dispatch", where type- and value-based dispatching are two of many kinds > of dispatching supported. If there's a third kind of dispatching (e.g. > a hybrid model), then the dispatching machinery would be open enough for > someone to write a new dispatcher class in Perl instead of warping the > language. Perl will easily be (is) powerful enough for someone to write a dispatcher class. Whether that will be easy to do doesn't matter, because some Damian will write a module to make it easy. What the A6 MMD's accomplish are the common case. There's one "most common" kind of dispatch that it implements. But Perl's not going to stop you from redefining the "multi" declarator, registering the routines, and using your own dispatcher. Perl 5 sure didn't :-) About the type system, considering MJD's article and some experience, I don't think it's Perl enough. It needs to be both stronger and less explicit. But that's a post for another day, when I get a proposal hashed out. > I haven't been following language syntax discussions recently, so I'll > refrain from proposing a straw man. That's all right. Personally, I correct people's syntax, but try not to let it get in the way of their ideas. Luke
Re: Multimethod dispatch?
[EMAIL PROTECTED] (Luke Palmer) writes: > It will still have a lot of power in text processing, and still be a > powerful "quicky" language, but that's no longer its primary focus -- > not to say that highly structured programming is. So, uh, what is? > And you can still do it the Perl 5 way in Perl 6. We're just taking > common idioms Your common and my common appear to differ! -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
Re: Multimethod dispatch?
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> You must not be following Perl 6 closely enough, then. Perl 6 is a
> "real" programming language now, as opposed to a "scripting" language.
Um, I've followed Perl6 closely enough to know that the distinction
between "real langauge" and "scripting language" is meaningless and
artificial when you're talking about Perl. Perl is quite simply a
'programming language', and it has been for years.
> It will still have a lot of power in text processing, and still be a
> powerful "quicky" language, but that's no longer its primary focus --
> not to say that highly structured programming is. Some applications
> want strong typing, some don't. That's why typing is optional (which
> is still driving me nuts as to how that's going to work).
You seem to have Perl5 confused with bash, sed or awk.
The main principles behind Perl are:
0: Get the job done (before the boss fires you)
1: TMTOWTDI
2: Use what works for you (i.e., Perl has no ideological bias)
I don't see what typing has to do with any of that. And I don't see why
optional typing or moving towards 'highly structured programming' is the
solution to fixing all of Perl5's warts.
> Well, type signatures are the only relevant information we have, so
> that's what we'll use. See below.
They're *not* the only relevant information that *we* have. They're
the only relevant information that a Java/C++ compiler has at compile
time. We can do better, since we're dispatching at runtime.
> Perl will easily be (is) powerful enough for someone to write a
> dispatcher class. Whether that will be easy to do doesn't matter,
> because some Damian will write a module to make it easy.
That's not my concern.
My concern is that there's a huge body of ideas and literature out there
that's worth stealing and putting into Perl6. MMD is one of those ideas.
However, the foundations of MMD are solving problems in the context of
limitations that do not necessarily exist in Perl6. Furthermore, concepts
that are roughly similar to MMD are *harder* to convey the because classic
MMD is baked in and taking up so much mindshare when it comes to
"dispatching".
> What the A6 MMD's accomplish are the common case. There's one "most
> common" kind of dispatch that it implements. But Perl's not going to
> stop you from redefining the "multi" declarator, registering the
> routines, and using your own dispatcher. Perl 5 sure didn't :-)
That's a cop-out.
Of course I can write my own dispatcher or warp the syntax to make my
pet idiom work. If the solution to every hard or unforseen problem is
"warp the syntax", then Perl6 is doomed to failure[*]. Don't forget that
Perl has many masters, and if the work-a-day Perl5 programmer is left in
the dust, then Perl6 will not have fufilled its mission.
The whole point behind Perl6 is to remove the warts and make easy things
easier. To me, this is a wart:
my %dispatch = (
param1 => sub {...},
param2 => sub {...},
);
sub foo {
my $param = shift;
if (my $sub = $dispatch{$param}) {
$sub->(@_);
} else {
warn "No such parameter: $param\n";
}
}
It's structurally similar to MMD, yet it is unsupported by MMD. And a
very easy technique for cleaning up Perl programs.
Z.
*: JBoss 4.0 is coming out, and if the pre-press reports are even remotely
correct, it was implemented using a high degree of AOP. The JBoss team
didn't need to warp Java syntax to accomplish it; instead, they rewrote
the class loader to support :before and :after subs dynamically appearing
and disappearing. I predict that this kind of extension, along with
macros, are going to be *MUCH* more useful than hacking the grammar.
The 'warping the syntax' escape hatch should only be used for hacking in
things like v-strings or lexical filehandles, *not* every pet extension
hook that someone could possibly want to see in the language.
Re: Multimethod dispatch?
Adam Turoff writes:
> On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> > It will still have a lot of power in text processing, and still be a
> > powerful "quicky" language, but that's no longer its primary focus --
> > not to say that highly structured programming is. Some applications
> > want strong typing, some don't. That's why typing is optional (which
> > is still driving me nuts as to how that's going to work).
>
> You seem to have Perl5 confused with bash, sed or awk.
>
> The main principles behind Perl are:
> 0: Get the job done (before the boss fires you)
> 1: TMTOWTDI
> 2: Use what works for you (i.e., Perl has no ideological bias)
Those are the general principles, yes, and the ones that make Perl so
enjoyable to use. But if you take a closer look, say at the builtins
and the features of Perl, you'll see that it's quite clearly a text
processing language. And that's fine -- it doesn't keep you from
doing non-text related stuff; it seems to find a way to make
anything text-related.
It's easy to get all those other non-text related things done with
CPAN. That's when text becomes less important, because there are
extensions written for everything.
> I don't see what typing has to do with any of that. And I don't see why
> optional typing or moving towards 'highly structured programming' is the
> solution to fixing all of Perl5's warts.
I don't think it's trying to fix all of Perl5's warts. And I don't
see what typing doesn't have to do with any of that. TMTOWTDI.
There are people who don't consider typing a programmer's aid at all,
and think that it's just there to help the compiler generate code
without working as hard. On the other hand, some people consider
typing a good error-checker and an idiom-enabling mechanism. Again,
that's why it's optional.
[snip]
> > What the A6 MMD's accomplish are the common case. There's one "most
> > common" kind of dispatch that it implements. But Perl's not going to
> > stop you from redefining the "multi" declarator, registering the
> > routines, and using your own dispatcher. Perl 5 sure didn't :-)
>
> That's a cop-out.
>
> Of course I can write my own dispatcher or warp the syntax to make my
> pet idiom work. If the solution to every hard or unforseen problem is
> "warp the syntax", then Perl6 is doomed to failure[*]. Don't forget that
> Perl has many masters, and if the work-a-day Perl5 programmer is left in
> the dust, then Perl6 will not have fufilled its mission.
I didn't say "warp the syntax" (though that is a useful one :-).
> The whole point behind Perl6 is to remove the warts and make easy things
> easier. To me, this is a wart:
>
> my %dispatch = (
> param1 => sub {...},
> param2 => sub {...},
> );
>
> sub foo {
> my $param = shift;
>
> if (my $sub = $dispatch{$param}) {
> $sub->(@_);
> } else {
> warn "No such parameter: $param\n";
> }
> }
>
> It's structurally similar to MMD, yet it is unsupported by MMD. And a
> very easy technique for cleaning up Perl programs.
And I don't see what's stopping someone from writing Dispatch::Value.
use Dispatch::Value;
sub foo($param is value('param1')) {...}
sub foo($param is value('param2')) {...}
What it seems you're wanting is it to be in the core. And I'm saying
that's irrelavent. There are thousands of great ideas out there, and
they can't all fit into Perl's core. That's why there's thousands of
modules on CPAN.
And I'm not saying it won't be in the core, either. It'll probably be
in the core module set.
Oh, sorry if I've turned this into too much philosophy. I'll happily
talk about more concrete things like ways it might be possible to
extend the standard dispatcher. Give me some more code to work with
-- more hypothetical examples -- and I'll talk about that.
> Z.
>
>
> *: JBoss 4.0 is coming out, and if the pre-press reports are even remotely
> correct, it was implemented using a high degree of AOP. The JBoss team
> didn't need to warp Java syntax to accomplish it; instead, they rewrote
> the class loader to support :before and :after subs dynamically appearing
> and disappearing. I predict that this kind of extension, along with
> macros, are going to be *MUCH* more useful than hacking the grammar.
>
> The 'warping the syntax' escape hatch should only be used for hacking in
> things like v-strings or lexical filehandles, *not* every pet extension
> hook that someone could possibly want to see in the language.
Again, I never said "warp the syntax".
Luke
Re: Multimethod dispatch?
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote: > What it seems you're wanting is it to be in the core. And I'm saying > that's irrelavent. There are thousands of great ideas out there, and > they can't all fit into Perl's core. That's why there's thousands of > modules on CPAN. Have you looked at the perl5 distribution lately :-) Graham.
Re: Multimethod dispatch?
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to be in the core.
Actually, no.
I expected that there'd be a way to extend runtime behavior through modules
like this hypothetical Dispatch::Value, Dispatch::Multimethods, or
Dispatch::Agent::Smith, but I'm seeing precious little evidence of that,
just allusions to MMD with the 'multi' keyword and all that.
As I said earlier, MMD is starting to give me a big case of The Fear
because it's predicated on offering behavior that heretofore hasn't been
widely used in Perl, and it's based around limitations that don't
necessarily exist in Perl. It's nice that Perl6 will extend its dynamic
range, but the whole reason for Perl6 in the first place is to fix
some of the warts in the current problem domain.
With some recent focus on MMD (mostly thanks to Dan's WTHI post, and my
discovery of TAMOP), I started to feel like MMD was good for a certain
style of programming, but necessarily ignores a "native" Perl5 idiom that's
equally powerful and perhaps preferable for a large set of problems.
I'm not trying to throw out the type system or cast MMD as pure evil.
Rather, I'm just poking around to make sure the dispatch machinery isn't
wired in for single dispatch/MMD without opening it up for extensions
via simple dispatch classes. *That* feature seems much more important
to me than wiring in MMD, since MMD could be implemented through
Dispatch::Multimethods or something. It's been done before with
Class::Multimethods, and I'll buy that there's a benefit to adding a
'multi' keyword to the language, but not if that's the last word for
variant dispatching...
If some dispatch class can use some syntax vaguely approximating the straw
man above, then this is just a tempest in a teapot and I'll move along.
But I haven't heard or seen anything concrete that dispatch behavior in
Perl6 can be user-defined without resorting to serious magic. Instead,
it's starting to sound suspiciously like "you can have any dispatching
behavior you want, so long as it's either single dispatch (modulo
sub/method semantics) or MMD". And that would be a net loss for Perl6.
Z.
Re: Multimethod dispatch?
> A better fitting solution wouldn't focus on classic > MMD, but simply "Dispatch", where type- and value-based > dispatching are two of many kinds of dispatching supported. I've always liked the sound of Linda's tuple spaces and view that as a nice generalized dispatch approach. Procedure calls are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
Re: Multimethod dispatch?
> A better fitting solution wouldn't focus on classic > MMD, but simply "Dispatch", where type- and value-based > dispatching are two of many kinds of dispatching supported. I've always liked the sound of Linda's tuple spaces and view that as a nice generalized dispatch approach. Procedure calls are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
