awaitEval in Concurrent Haskell

[Colin Runciman]

Claus,

>  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?-)
>
Agreed. Current plan is to use Drift

>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.
>
Yes indeed.  One ideally wants assertions to be the 'first consumers' of
data as it becomes evaluated. But the whole business of how best to
define and use assertions is exactly what my student should
be exploring in his project -- are you reading this Dan?!  

Colin R