[Haskell] threading mutable state through callbacks

[John Meacham]

On Wed, Oct 13, 2004 at 10:01:08AM +0100, Adrian Hey wrote:
> On Wednesday 13 Oct 2004 3:36 am, Wolfgang Thaller wrote:
> > b) Some predetermined order, with semantics like mdo:
> >
> > John Meacham wrote:
> > > The basic idea is that your entire program behaves as if in a giant
> > > 'mdo' block, ordered in module dependency order.
> >
> > What is module dependency order? There's no such thing when there are
> > circular dependencies, and when there aren't any, it might still depend
> > on the order of import directives, which is probably not something I
> > want program semantics to depend on.
> > I feel that In a large program, you'll probably get more surprises from
> > this.
> > The good thing is that you can always use unsafeInterleaveIO to get the
> > other semantics back, so we should probably investigate this further.
> 
> Yes, this is something I wasn't too clear about, largely because I'm not
> too certain about the precise semantics of mdo (never actually used it).
> 
> John's proposal seemed like a good formalisation of what a compiler might
> do in reality to implement this. But if it means imposing some order on
> things (other than the dependency "on demand" ordering that we currently
> get with the unsafePerformIO hack) I'm not sure that's a good idea.
> 
> I would rather have the order unspecified and make it the programmers
> responsibility to control this, if significant. Having the correctness
> of programs dependent on ordering of top level definitions or imports
> is not a discipline Haskellers are used to. If this is the case with
> John's proposal, it seems like it could cause trouble in the long run :-(

Yeah, there actually is not a real need to formalize the order, since
the top-level bindings are going to be recursive and lazy, A specific
order doesn't matter much more than what order you allocate your CAFs
in.

However, since IO actions can have side effects and enforce evaluation,
one may specifically write code which will be able to observe the order.
This doesn't seem like that big of a deal, since the result of an IO
action is allowed in some sense to depend on implementation or undefined
behavior and it certainly shouldn't be a problem for the common cases of
IORefs, MVars and global Channels. 

I would be perfectly happy with just specifying an unknown order, or
just that all the bindings in a single module be ordered in the same way
as they appear in the module, but intramodule orders be unspecified.

the method I posted happens to execute the actions in dependency order,
but there is no need to guarentee that.

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈