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.
