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
