[Haskell] threading mutable state through callbacks
Wolfgang Thaller
wolfgang.thaller at gmx.net
Tue Oct 12 22:36:11 EDT 2004
Well, Wadler's Law of Language Design has been disproved. We seem to
agree on the syntax, that is, global "foo <- bar" bindings, and we're
actually discussing semantics. That's great!
Just for the record, I want exactly what Adrian proposed.
There seem to be two interesting points about the semantics:
1) To prevent unwanted typecasts, all toplevel "<-" bindings must be
monomorphic.
This restriction should be sufficient to keep everything perfectly safe
(does anyone disagree?), except for...
2) Evaluation order.
That's what everyone has been fighting about.
So what are our options?
a) unsafePerformIO - like.
This has some potential for abuse, but it works.
Lazy initialization is a good thing for large programs - and that
includes side effects. People deliberately do that in OO programs -
you'll find methods that look like getSomeMemberVar accessor methods,
but the first time they're invoked, they'll actually initialize a part
of the program. I'd actually like to abuse this feature that way.
Anyway, the non-determinism this introduces is not nearly as bad as
what you get from concurrency or even signal handlers...
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.
Is there some option c) that I overlooked?
Another question is, if the order is to follow program order, what do
we still need main for? Ugh...
Cheers,
Wolfgang
More information about the Haskell
mailing list