monads

Difference between State, ST, IORef, and MVar

我是研究僧i 提交于 2019-11-28 13:17:19
问题 I am working through Write Yourself a Scheme in 48 Hours (I'm up to about 85hrs) and I've gotten to the part about Adding Variables and Assignments. There is a big conceptual jump in this chapter, and I wish it had been done in two steps with a good refactoring in between rather then jumping at straight to the final solution. Anyway… I've gotten lost with a number of different classes that seem to serve the same purpose: State , ST , IORef , and MVar . The first three are mentioned in the

How to use an Alex monadic lexer with Happy?

我的梦境 提交于 2019-11-28 09:16:04
I'm trying to learn using Alex + Happy to build parser, in particular I'm interested in learning to use the monad wrapper of Alex. I have already looked at the documentation of Alex and Happy but I they are both, for me, really lacking any useful information on using them together. I managed to make them work together with the basic and posn wrappers, but I'm at a loss with monad . I have already looked at different question on SO about Alex, Happy and monadic lexers (including: Are there any tutorials on building a simple interpreter using Alex + Happy? but none is able to provide a simple

Restricting a monad to a type class

梦想与她 提交于 2019-11-28 09:08:17
In Haskell, is there a way to restrict a monad M a so that a satisfy a type class constraint? I am translating the probabilistic modeling example from F# to Haskell . However, in Haskell, I omitted support because it would change data Distribution a to data (Ord a) => Distribution a . With this change, I get the following error: ...probabilisticModeling.hs:42:13: Could not deduce (Ord a) from the context () arising from a use of `always' at ...probabilisticModeling.hs:42:13-18 Possible fix: add (Ord a) to the context of the type signature for `return' In the expression: always In the

Continuation monad for a yield/await function in Haskell

两盒软妹~` 提交于 2019-11-28 08:27:41
问题 I want to create an automata type with a type like this: newtype Auto i o = Auto {runAuto :: i -> (o, Auto i o)} I know this is the type of the Automata arrow, but I'm not looking for an arrow. I want to make this a monad, so presumably its going to have a type like newtype Auto i o a = ???? What goes here? with a function like this: yield :: o -> Auto i o i So when I call "yield" from within the Auto monad the "runAuto" function returns a pair consisting of the argument to "yield" and the

What is the default type evaluation of MonadPlus in Haskell?

若如初见. 提交于 2019-11-28 07:47:34
问题 I have the following code: import Control.Monad coin :: MonadPlus m => m Int coin = return 0 `mplus` return 1 If I evaluate coin :: Maybe Int on the interpreter, it prits Just 0 . That's normal because of the implementation of Maybe as instance of MonadPlus. If I evaluate coin :: [Int] on the interpreter, it prints [0, 1] , because the implementation of mplus on list is an append . But if I evaluate coin , without any type decorators, it prints 0 . Why? What type does the interpreter

Is mapM in Haskell strict? Why does this program get a stack overflow?

限于喜欢 提交于 2019-11-28 07:45:35
问题 The following program terminates correctly: import System.Random randomList = mapM (\_->getStdRandom (randomR (0, 50000::Int))) [0..5000] main = do randomInts <- randomList print $ take 5 randomInts Running: $ runhaskell test.hs [26156,7258,29057,40002,26339] However, feeding it with an infinite list, the program never terminates, and when compiled, eventually gives a stack overflow error! import System.Random randomList = mapM (\_->getStdRandom (randomR (0, 50000::Int))) [0..] main = do

Why use such a peculiar function type in monads?

假如想象 提交于 2019-11-28 07:01:06
问题 New to Haskell, and am trying to figure out this Monad thing. The monadic bind operator -- >>= -- has a very peculiar type signature: (>>=) :: Monad m => m a -> (a -> m b) -> m b To simplify, let's substitute Maybe for m : (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b However, note that the definition could have been written in three different ways: (>>=) :: Maybe a -> (Maybe a -> Maybe b) -> Maybe b (>>=) :: Maybe a -> ( a -> Maybe b) -> Maybe b (>>=) :: Maybe a -> ( a -> b) -> Maybe b Of

Using return vs. not using return in the list monad

余生长醉 提交于 2019-11-28 06:44:56
I started my Grand Haskell Crusade (GHC :) ) and I am a bit confused with monads and IO functions. Could anyone explain simply what is the difference between those two functions? f1 = do x <- [1,2] [x, x+1] -- this is monad, right? f2 = do x <- [1,2] return [x, x+1] The results are: *Main> f1 [1,2,2,3] *Main> f2 [[1,2],[2,3]] The other answers here are correct, but I wonder if they're not quite what you need... I'll try to keep this as simple as possible, just two points: Point 1. return is not a special thing in the Haskell language. It's not a keyword, and it's not syntactic sugar for

Combining Free types

空扰寡人 提交于 2019-11-28 06:27:02
I've been recently teaching myself about the Free monad from the free package, but I've come across a problem with it. I would like to have different free monads for different libraries, essentially I would like to build DSLs for different contexts, but I would also like to be able to combine them together. As an example: {-# LANGUAGE DeriveFunctor #-} module TestingFree where import Control.Monad.Free data BellsF x = Ring x | Chime x deriving (Functor, Show) type Bells = Free BellsF data WhistlesF x = PeaWhistle x | SteamWhistle x deriving (Functor, Show) type Whistles = Free WhistlesF ring :

Can someone explain to me why the app function of ArrowApply makes them as powerful as monads?

两盒软妹~` 提交于 2019-11-28 06:20:59
So I'll break my question into 4 parts, but first some background: I feel relatively comfortable with Monads, but not very comfortable with Arrows. I suppose the main problem I have with them is, I don't see what they are useful for. Whether formally correct or not, I understand Monads to be a tool that allows us to introduce side effects from computation. As they generalize program fragments from pure values to values boxed with other actions. From my shotgun "read all the papers" approach to learning about arrows, I've come across two conflicting viewpoints: A. Arrows are more powerful than