awaitEval in Concurrent Haskell

[Colin Runciman]

C.Reinke wrote:

>I'm not sure whether I understand what you have in mind
>later on, but this first part sounds so remarkably like
>something I've seen before, that I'll take my chances.
>
>Do you remember Andy Gill's Hood from long ago?
>
>Inside its implementation, it had a very similar problem:
>writing information about an observed structure to some
>observation trace, but without forcing premature evaluation
>of the structure under observation ...
>Nothing happens as long as the thing under observation is not
>inspected by its context. Then, and precisely then, the
>unsafePerformIO kicks in to record a piece of information and to
>return the outer part of the thing, wrapping its components into
>fresh observers.
>
>Andy used this to store observations in a list, to be processed at
>the end of the program run, but you can just as well send the
>observations during evaluation, e.g., to a concurrent thread (with
>the usual caveats). In particular, the sequencing of information
>becoming available was detailed enough to inspire my own GHood;-)
>
>With no implementation slot free, something like this might get your
>student's project unstuck (e.g., replace sendObservation by assert)?
>After all, my favourite justification for unsafePerformIO is as an
>extension hook in the runtime system..
>
Yes, we considered using something like the Hood technique.   The problem
is that a path-annotated observation sequence is a rather unwieldy 
representation of
a data structure. As you say, Hood stores the observations to file, 
where they can be
post-processed beyond the confines of the observed Haskell computation. 
 The scheme
works because the whole purpose of the application is just to observe 
the data in
the order that it becomes evaluated.

What we are after is a little different.  We need a way of attaching
an arbitrary boolean predicate to a data structure, with its own pattern 
of demand for
the components, but only proceeding as and when the needed components 
become evaluated
by the normal computation.  Perhaps "data-driven" is misleading; we want 
the sequence
of evaluation for an asserted predicate to remain demand driven as 
usual, but for progress
in that sequence to be constrained by the rule that no evaluation of the 
data structure
argument may be forced.

Colin R