Search Results

Search found 7 results on 1 pages for 'martingw'.

Page 1/1 | 1 

  • How can I make a Maybe-Transformer MaybeT into an instance of MonadWriter?

    - by martingw
    I am trying to build a MaybeT-Transformer Monad, based on the example in the Real World Haskell, Chapter Monad Transformers: data MaybeT m a = MaybeT { runMT :: m (Maybe a) } instance (Monad m) => Monad (MaybeT m) where m >>= f = MaybeT $ do a <- runMT m case a of Just x -> runMT (f x) Nothing -> return Nothing return a = MaybeT $ return (Just a) instance MonadTrans MaybeT where lift m = MaybeT $ do a <- m return (Just a) This works fine, but now I want to make MaybeT an instance of MonadWriter: instance (MonadWriter w m) => MonadWriter w (MaybeT m) where tell = lift . tell listen m = MaybeT $ do unwrapped <- listen (runMT m) return (Just unwrapped) The tell is ok, but I can't get the listen function right. The best I could come up with after 1 1/2 days of constructor origami is the one you see above: unwrapped is supposed to be a tuple of (Maybe a, w), and that I want to wrap up in a Maybe-Type and put the whole thing in an empty MonadWriter. But the compiler complains with: Occurs check: cannot construct the infinite type: a = Maybe a When generalising the type(s) for `listen' In the instance declaration for `MonadWriter w (MaybeT m)' What am I missing?

    Read the article

  • Has anyone ever encountered a Monad Transformer in the wild?

    - by martingw
    In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log it's progress, to have some kind of error handling / computation short circuit... Things that can be modelled nicely by Reader-, Writer-, Maybe-monads and the like in Haskell and composed together with monad transformers. But there seem to some drawbacks: The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures, and they inflict some performance penalty. So I'm wondering: Are monad transformers best practice when dealing with those common tasks mentioned above?

    Read the article

  • How can I compile a GUI executable with ghc?

    - by martingw
    I ported a little Haskell program I wrote from Mac to Windows. It's a GUI application (wxHaskell, compiled with ghc 6.12.1), so it does not need the command prompt window to open. It does so, anyway, so my question: What must I do so that the program starts without opening a prompt window first? Is there some ghc switch for this?

    Read the article

  • Why does s ++ t not lead to a stack overflow for large s?

    - by martingw
    I'm wondering why Prelude> head $ reverse $ [1..10000000] ++ [99] 99 does not lead to a stack overflow error. The ++ in the prelude seems straight forward and non-tail-recursive: (++) :: [a] -> [a] -> [a] (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys So just with this, it should run into a stack overflow, right? So I figure it probably has something to do with the ghc magic that follows the definition of ++: {-# RULES "++" [~1] forall xs ys. xs ++ ys = augment (\c n -> foldr c n xs) ys #-} Is that what helps avoiding the stack overflow? Could someone provide some hint for what's going on in this piece of code?

    Read the article

  • Why is there "data" and "newtype" in Haskell?

    - by martingw
    To me it seems that a newtype definition is just a data definition that obeys some restrictions (only one constructor and such), and that due to these restrictions the runtime system can handle newtypes more efficiently. Ok, and the handling of pattern matching for undefined values is slightly different. But suppose Haskell would only knew data definitions, no newtypes: Couldn't the compiler find out for himself whether a given data definition obeys these restrictions, and automatically treat it more efficiently? I'm sure I'm missing out on something, these Haskell designers are so clever, there must be some deeper reason for this...

    Read the article

  • How can I implement a tail-recursive list append?

    - by martingw
    A simple append function like this (in F#): let rec app s t = match s with | [] -> t | (x::ss) -> x :: (app ss t) will crash when s becomes big, since the function is not tail recursive. I noticed that F#'s standard append function does not crash with big lists, so it must be implemented differently. So I wondered: How does a tail recursive definition of append look like? I came up with something like this: let rec comb s t = match s with | [] -> t | (x::ss) -> comb ss (x::t) let app2 s t = comb (List.rev s) t which works, but looks rather odd. Is there a more elegant definition?

    Read the article

1