If something like this isn't on CPAN, you should seriously consider putting it on there
I second that, although I would suggest better naming conventions. I am not a fan of abbreviations, and especially ones that are so similar and potentially confusing to the eye (i.e. - seq, spec).
| [reply] |
CPAN already has Set::CrossProduct, Object::Iterate, and Tie::Cycle. I think those three modules cover just about everything discussed in the node, and anything they don't I can add.
--
brian d foy <bdfoy@cpan.org>
| [reply] |
brian, thanks for the pointers!
CPAN already has Set::CrossProduct, Object::Iterate, and Tie::Cycle. I think those three modules cover just about everything discussed in the node, and anything they don't I can add.
While the overlap of my meditation's sequences and your modules is
large, I would like to point out some philosophical differences
between our approaches. (These aren't pros or cons – just differences.)
- The sets that sequences represent are implicit. This lets them be
defined on the fly so that, for example, you can efficiently take the
Cartesian products of arbitrary sequences (that themselves may the
products of sequences). This also lets you work (space efficiently)
with sequences whose lengths cannot be known until they are exhausted. However, the lengths of sequences cannot be known until they are exhausted.
- You can observe the cyclical wrap-around point of a sequence.
This lets the wrap-around be used as a trigger for other events, such
as terminating a parallel merge operation or advancing the next most-significant sequence in a series of
sequences.
- I think that it's easier to build up a chain of operations with
sequences than with the collection of CPAN modules.
For example, it seems like you must forego the space-saving benefits of iterators to take the product of an earlier product, which discourages the use of products in computational chains.
- Nevertheless, I think that the CPAN modules are probably more
practical for the functionality where our libraries overlap.
My sequences are first and foremost meditative material. In their
present form, they aren't suited for production use.
If you're looking to add features, it would be nice if
Set::CrossProduct could take the product of
arbitrary iterators. :)
Cheers,
Tom
| [reply] |
