[Haskell-cafe] Four Designs for a Monad

[Zemyla]

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
    prolog
    in <- arg
    getArg R0, in
    addi R0, R0, 1
    retr R0

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
JIT state.

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
with unsafePerformIO.
Cons: Referential integrity could still be violated.

4) Lightning a, which would be a free monad over the Lightning operations
allowed.
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?

Thanks,

Paul Drees
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150602/b8a06f9a/attachment.html>