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

Reply via email to