awaitEval in Concurrent Haskell
Mon, 17 Feb 2003 18:55:19 +0000
> 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