[Haskell-cafe] Towards an IO-Comonad that preserves referential
transparency (was: "comonads, io" Jan 02, 2003)
Sven Biedermann
Sven.Biedermann at biedermann-consulting.de
Fri Nov 3 02:53:56 EST 2006
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
>
More information about the Haskell-Cafe
mailing list