Multimethod dispatch?
Adam Turoff
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.
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.
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.
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.
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.
I haven't been following language syntax discussions recently, so I'll
refrain from proposing a straw man.
Z.
*: http://dev.perl.org/rfc/256.pod
**: http://search.cpan.org/author/DCONWAY/Class-Multimethods-1.70
***: http://www.sidhe.org/~dan/blog/archives/000194.html
Luke Palmer
> 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
Simon Cozens
> 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
Adam Turoff
> 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.
Luke Palmer
> 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
Graham Barr
> 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.
Adam Turoff
>
> 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.
Me
> 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
Me
> 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