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