Something that may possibly be relevant to this discussion as an object lesson
...
In the near future, probably next week, I'm going to re-implement the guts of my
Set::Relation module (for Perl 5, on CPAN now), from an eagerly evaluated
sometimes mutable or immutable object, to a often-lazily evaluated always
immutable object. This is partly to help improve its performance but also to
make it better in other ways. Other design changes will be made too, but I said
the most significant one.
That module will subsequently be translated to Perl 6.
How this can be an object lesson is that it involves slightly complicated types
and operators, all of which are conceptually pure, but which internally make use
of hashing or caching for performance. Moreover, various user inputs to this
module would be naturally mutable, eg inserting a Hash into a Set of Hash, but
we don't want the Hash to mutate after being inserted into the Set; also the
values of the Hash may be arbitrarily complex or any type, mutable or immutable.
The laziness is partly done so that you can make the analogy of "%foo<bar> =
$baz" work on an immutable %foo, having semantics like "%foo = {*%foo,
:bar($baz)}" while still having good performance. (My "*%foo" means flatten
foo, but that syntax is probably outdated.)
There are other reasons.
But I think we can use this as one early proof of concept or practical
experimentation of how to handle matters of pure functions and handling side
effects or what have you.
After that Set::Relation is improved, then Muldis::Rosetta would then be
implemented, doing that on a larger scale.
-- Darren Duncan
