awaitEval in Concurrent Haskell

[C.Reinke]

> Actually a mild variant of Claus's proposal seems to work out
> quite well.  Another way to avoid the problems with types is
> to use a multi-parameter type class.  Little example attached.

Glad to be of help. The need to shadow the data types is a bit
annoying, but then the whole generic bit would preferably be
generated anyway. Template Haskell to the rescue, or Drift?-)

> .. the availability of data would only be detected if the demand
> that prompted its evaluation was in the context of the
> assertion-tagged expression.  Yes?

Yes - same issues with sharing as in Hood. You could tag the
expression before sharing, though. And in your application, you
might actually prefer to have that fine distinction: just because
someone else has evaluated a shared expression far enough to allow
your assertion to be evaluated, that doesn't mean that this
assertion will be relevant to the program run.

There is still something I don't understand about your
specification: the assertions take on a post-mortem character - by
the time the assertion fails, the main thread might have run into
trouble already (after all, its evaluation drives the assertion). 

So while this would work,

  let l = ""
  print $ length $ assert "non-empty l" (not . null) l

this might not be a good idea:

  let l = ""
  print $ head $ assert "non-empty l" (not . null) l

At best, you get both the main-thread error and the assertion-thread
failure message.  That's why I was asking what you intend to do with
the assertions.

Cheers,
Claus