Nathan Wiger wrote:
> "David L. Nicol" wrote:
> >
> > These things sound like perfectly reasonable CPAN modules.
> > What's the block prevenenting their implementation w/in the
> > perl5 framework?
>
> Jeremy and I are working on a general purpose matrix/unmatrix function
> that may well be core-worthy. This would allow arbitrary reshaping of 2d
> (Nd?) arrays into any form imaginable.
>
Actually, I still remain to be convinced that RFC 81 (Lazily evaluated list
generation functions) isn't already this generic tool (when used as an index
to another list). When you've got some examples of using your proposed
'reshape' (or whatever it'll be called), I'll see what the same code looks
like with RFC 81 notation...
> However, I would probably argue that zip/unzip/merge/unmerge/whatever go
> into a module (Math::Matrix?) since they'll probably just be specialized
> calling forms of matrix/unmatrix. I think the trend is to put a lot of
> formerly-core functions and features in modules, especially if subs get
> fast enough (and it sounds like they're going to).
>
Definitely, if the generic foundation for them (lazily generated lists,
reshape, ...) is there. But to answer Nick's question, the reason they're
not in Perl 5 in this way at the moment is that Perl 5 doesn't provide the
foundation required for them.
Although it's easy enough to write a zip or partition function in Perl 5,
because it can't be evaluated lazily and would therefore be useless for any
real numeric programming. Also there's no use in having just array
reshaping functions if the rest of the baggage required to avoid explicit
loops isn't in the language.
In general, if array notation (i.e. working with lists without explicit
loops) isn't reliably efficient, I would always use explicit loops instead
(since the loss of clarity is more than outweighed by the increased speed
and lower memory use).
