awaitEval in Concurrent Haskell

[Claus Reinke]

> 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. 

Instead of generating path-annotated observation sequences, you could use
the same trick to trigger other demand-driven actions, but I think I can see the 
problem: you'd have a sequence of actions in demand-for-x-driven order
on one side and an expression  (predicate applied to x) on the other. 

Intriguing problem..

It may be possible to get the two representations together by applying the
predicate to a "reader" for x, generated from x, which would complement 
something like Hood's "writer" for x, generated from x. Just as the context
demanding parts of x isn't aware of triggering observations, the predicate
depending on parts of x need not be aware of having to wait for those
observations, and MVars could provide the plumbing between the implicit
readers and writers. See below for an outline.

> 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; ...

No, seems quite apt to me: demand for some x makes parts of x available,
and you would like the availability of that data to drive the evaluation of
some (predicate x), provided that there is demand for the result. Btw, there
is no guarantee that there'll ever be sufficient data for the evaluation of
those predicate applications, so they won't be on the main evaluation 
thread - what do you do with their results?

Anyway, here's an outline of the reader/writer idea:

First, we can modify the Hood trick slightly to generate "writers" for the 
xs in question (again taking pairs as examples for the generic functions):

    observeW mv (a,b) = unsafePerformIO $ do
        mva <- newEmptyMVar
        mvb <- newEmptyMVar
        putMVar mv (mva,mvb)      -- "(,) has been observed here"
        return (observeW mva a,observeW mvb b)

Then, we can generate a complement of "readers" to guard copies of 
those xs from premature evaluation by the predicates (note that all data
come via the hidden plumbing here - the parameter is for typing only):

    observeR mv (a,b) = unsafePerformIO $ do
        (mva,mvb) <- takeMVar mv     -- "(,) has been observed elsewhere"
        return (observeR mva a,observeR mvb b)

We could now hack up some assertion scheme, employing observeR
to guard x from some predicate, and observeW to drive that predicate
by demand for x from the evaluation context:

    assert :: String -> (a->Bool) -> a -> a
    assert l p x = unsafePerformIO $ do
        mv <- newEmptyMVar
        forkIO $ putStrLn $ l++show (p (observeR mv x)
        return $ observeW mv x

The side-thread for the predicate should print only to the extent that
(p x) depends only on parts of x observed in the main thread, hopefully?-)

It seems that the reader/writer scheme relies on all constructors being 
polymorphic, as x::((,) a b) and mv::MVar ((,) (MVar a') (MVar b')) are
used with the same (,). A workaround would be to package constructors 
separately from their components, using

        putMVar mv ((,),mva,mvb)

in the writer and

        (c,mva,mvb) <- takeMVar mv
        return $ c (observeR mva a) (observeR mvb b)

in the reader.

Hope this makes some sense. Naturally, it is completely untested,
and whether or not it is as unsafe as it looks is left as an exercise;-)

Cheers,
Claus