[Haskell-cafe] Four Designs for a Monad
zemyla at gmail.com
Tue Jun 2 19:39:45 UTC 2015
I'm working on writing a Haskell wrapper for the GNU Lightning code
generation library (http://www.gnu.org/software/lightning/), which in C
consists of a series of macros that write to a certain global state in a
pointer _jit, such as jit_add or jit_call. Now, I figure that can be
wrapped fairly simply in a monad, which we'll call the Lightning monad:
-- syntax given here is just a sample.
incr = lightningEmit $ do
in <- arg
getArg R0, in
addi R0, R0, 1
However, I've come up with four possible designs for the Lightning monad.
All but one would be reader monad transformers holding the pointer to the
1) Lightning m a, where m is a MonadIO.
Pros: Users have the power of the monads they are using within.
Cons: Complexity, especially with having to handle monads with multiple
returns like ListT.
2) Lightning a, which just wraps IO, and is a MonadIO.
Pros: Allows the use of other IO functions in the monad.
Cons: Allows the use of other IO functions in the monad.
3) Lightning a, which just wraps IO, and is not a MonadIO.
Pros: Simplicity; possibly permitting the code generation to be unwrapped
Cons: Referential integrity could still be violated.
4) Lightning a, which would be a free monad over the Lightning operations
Pros: Evaluation (in the IO monad) would be certain to be pure, which would
permit or accommodate it being a monad transformer, or converted to a pure
function on architectures where the Lightning library is not available.
Cons: Assembling, then disassembling to reassemble, a long list of
instructions produces significant overhead, rendering it less suitable for
JIT purposes. Interacting with the generated code is more difficult.
Are there any other options I am missing? Are there any possibly
game-changing pros or cons I have failed to notice?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe