I'm not quite buying into this.
There are some things that are just easier with this style of thinking.
Its a higher level construct. Akin to telling your interior decorator
that you'd like the furniture to match the wallpaper. You've left
out all the details but the decorator can easily see what you're talking
about.
So calling, adding a little bit of Prolog, is hard to call anti-perl.
Another way of looking at it, is why have everybody and his dog write
the code when perl can get it right.
I just prefer to avoid writing loops. It just adds to the likelyhood
of bugs. using map/grep, and family would just reduce the incidence.
And reduce (and perhaps some of the more interesting APL operators may
be worthwhile. Just as a method of avoiding hand coding loops.)
Why bother having hashes? Isn't easily implemented in a Module?
I would respectfully suggest that you fine tune the algorithm that
would help decide how to decide where to file items
fundemental built-in (perl, mini/micor/nano-perl)
understood by perl, and loaded on demand
shipped with perl
CPAN
or
not now, some other time
get out of here and never come back.
<chaim>
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =item Functional Programming
PRL> Just because Perl has a C<map> operator, this doesn't make it a
PRL> functional programming language. Perl has always been squarely
PRL> procedural, and so things like C<reduce> and C<curry> and other cookery
PRL> terms are somewhat out of place; they can be far more easily and
PRL> appropriately implemented as extension modules I<post hoc>. By all
PRL> means, let's generalise the problem, and make it easier to define your
PRL> own syntax, but let's not add the entirety of LISP and ML to the core.
PRL> The CS types may love it, but I'm a programmer and I don't.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
