[Haskell-cafe] Practical Haskell question.

Claus Reinke claus.reinke at talk21.com
Mon Jun 25 06:06:25 EDT 2007


>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



More information about the Haskell-Cafe mailing list