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.