applicative

问题 I have a function parseArgs :: [String] -> StdGen -> IO () which selects the function to run. The main looks like main = parseArgs <$> getArgs <*> getStdGen >>= id The problem I have, parseArgs <$> getArgs <*> getStdGen is of type IO (IO ()) , which I extract using (>>= id) which is of type Monad m => m (m b) -> m b . Is there a way to avoid requiring the "extraction" of the value while having just a single line function? 回答1: The easiest way would be with join : main = join $ parseArgs <$>

问题 Suppose I have a list of numbers and list of functions: val xs: List[Int] = List(1, 2, 3) val fs: List[Int => Int] = List(f1, f2, f3) Now I would like to use an Applicative to apply f1 to 1 , f2 to 2 , etc. val ys: List[Int] = xs <*> fs // expect List(f1(1), f2(2), f3(3)) How can I do it with Scalaz ? 回答1: pure for zip lists repeats the value forever, so it's not possible to define a zippy applicative instance for Scala's List (or for anything like lists). Scalaz does provide a Zip tag for

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 4 years ago . Why is the function for lifting a value into a functor named pure in Control.Applicative? 回答1: Think of pure as an adjective. foo <*> pure 4 = foo applied on a pure value 4 . (As for the exact reason why it's called pure , probably only McBride and Paterson will know.) 回答2: It's a little like fromInteger . Its

问题 I am currently learning Applicatives in Haskell. If I am not wrong, there are two different Applicative instances for Lists, ( List and ZipList - the second being defined as a newtype wrapping a List value). The ZipList applicative instances seems more intuitive for me. It might be a dumb question, but is there a specific reason ZipList is not the default Applicative instance for Lists. pure (+) <*> [1,2,3] <*> [4,5,6] -- [5,6,7,6,7,8,7,8,9] pure (+) <*> ZipList [1,2,3] <*> ZipList [4,5,6] --

问题 The wiki on www.haskell.org tells us the following about Applicative Transformers: So where are applicative transformers? The answer is, that we do not need special transformers for applicative functors since they can be combined in a generic way. http://www.haskell.org/haskellwiki/Applicative_functor#Applicative_transfomers I tried the following in order to try to combine a bunch of applicative functors. But all I got was bunch of errors. Here is the code: import Control.Applicative import

问题 In McBride and Paterson's 'Applicative programming with effects' they introduce some lovely syntactic sugar for lifting a pure function: [| f x y z |] for f <$> x <*> y <*> z and I recall someone somewhere else using li f w x y z il or il f v w x y z li , and I thought/hoped that might be because it could be defined using some existing language feature and cunning definition of li and il . I can't find any reference to this beyond the paper, and assuming that [| and |] aren't likely to turn

问题 Suppose I need to run two concurrent computations, wait for both of them, and then combine their results. More specifically, I need to run f1: X1 => Y1 and f2: X2 => Y2 concurrently and then call f: (Y1, Y2) => Y to finally get a value of Y . I can create future computations fut1: X1 => Future[Y1] and fut2: X2 => Future[Y2] and then compose them to get fut: (X1, X2) => Future[Y] using monadic composition. The problem is that monadic composition implies sequential wait . In our case it implies

问题 There is an instance Monoid a => Monoid (Const a b) for the Const functor from Control.Applicative . There is also an instance Monoid m => Applicative (Const m) . I would therefore expect that there is also an instance Monoid m => Alternative (Const m) that coincides with the one for Monoid . Is this just an omission that should be fixed, or is there a deeper reason? 回答1: I believe there is a deeper reason. While it seems there is no canonical set of rules for Alternative , in order for

问题 There is an instance Monoid a => Monoid (Const a b) for the Const functor from Control.Applicative . There is also an instance Monoid m => Applicative (Const m) . I would therefore expect that there is also an instance Monoid m => Alternative (Const m) that coincides with the one for Monoid . Is this just an omission that should be fixed, or is there a deeper reason? 回答1: I believe there is a deeper reason. While it seems there is no canonical set of rules for Alternative , in order for

问题 I'm a haskell beginner going through aeson, learning more about both by parsing some data files. Usually when there's a data file, may it be .json , a lua table, .csv format or others, and you want to parse them, there's always a chance of error. For example, a simple .json file like this "root": { "m1": { "key1": "value1", "key2": 2 }, "m2": { "key1": 1 }, } Has two oddities: "m1" has two subkeys, one has a value in String and one in Int . "m2" has only one subkey, and it has same key as the