Hello Nick, Am 02.11.2006 um 20:51 schrieb Nicolas Frisby:
OI has been lingering in the back of my mind during my own comonadic adventures.
Did you enjoy them?
One thing that's bothered me is the signature of comain.
comain :: OI () -> ()
If the OI comonad is to represent values "in the context of the RealWorld", and yet we can have multiple and differing copies of the RealWorld context, then this seems to match the multiple worlds perspective (which is why I think Kieburtz' experimental implementation was doomed to violate referential transparency). That is I want any deterministic program to be of top-level type:
comain :: OI () -> OI ()
The intuition is that the program as a whole receives the initial world description, then is allowed to duplicate and manipulate that world in any number of ways, but it has to choose one final world as its choice. All other real worlds are discarded. The OI () -> () signature doesn't allow for the program to tell me what the resulting RealWorld ought to be.
I think of signature OI a -> b as a constraint: there's no hidden agenda inside the comonad. The future of the comonad doesn't depend on its history. In a comonad using OI a -> OI b, anything can be hidden. So, if the comonad hasn't a hidden agenda, there's no point in choosing a final world. Hence, OI a -> b seems adequate to me.
An implementation of this doesn't seem impossible (as opposed to improbable) for file IO or references (your filesystem/cell store would have to be transactional and "multi-ported"). It does become a bit mind boggling for concurrency or any other multi-agent paradigm (networking, screen and keyboard IO, etc.)--it seems that the other agents would have to be savvy to the multiple worlds perspective.
What is "multi-ported"?
Transactional systems certainly seem like a ripe application area for the Product comonad with a RealWorld abstract data type as the carried context.
My apologies for not actually commenting on your code.
Thank you for use comments.
Nick