Now I've got a situation I can't figure out how to resolve. I want to have a set of actions which are executed sequentially, but which, before I even start to execute the first one, have been inspected for legality and/or plausibility. Consider this kind of sequence:
do x <- performActionA y <- performActionB z <- performActionC return $ calculateStuff x y z
as has been pointed out, there is an issue as to whether the conditions for legality can depend on runtime information. if they don't, you could try to express the capabilities needed by each of the actions in their types, and collect the types when composing the actions. i first saw this trick used for type-based bytecode verification in The Functions of Java Bytecode Mark P. Jones. In Proceedings of the OOPSLA '98 workshop on Formal Underpinnings of Java, Vancouver, BC, Canada, October 1998. http://web.cecs.pdx.edu/~mpj/pubs/funJava.html but i'm sure that somewhere in the wealth of HList work, there'll be something similar, updated for todays ghc!-) if the conditions are static, but their validity might depend on runtime info, you'd need to map the types expressing the capabilities required back down to functions checking their availability, and execute those checks before running the composed actions. if the conditions themselves might change as actions are computed at runtime, you might still be able to use a transaction-based approach: only execute the actions in a sandbox at first, so that you can abandon the transaction if any of the actions in it fail, and commit to the transaction (turning the sandbox changes into real changes) only if all actions in it succeed. in a way, you're executing the transaction twice, once only to check it will go through, then again for the actual updates. hth, claus