monads

Why wrapping the Data.Binary.Put monad creates a memory leak? (Part 2)

别来无恙 提交于 2019-12-01 17:23:04
As in my previous question , I'm trying to wrap the Data.Binary.Put monad into another monad so that later I can ask it questions like "how many bytes it's going to write" or "what is the current position in file". Before, I thought that understanding why it leaks memory while using a trivial (IdentityT?) wrapper would lead me to solving my problem. But even though you guys have helped me resolve the problem with the trivial wrapper, wrapping it with something usefull like StateT or WriterT still consumes too much memory (and usually crashes). For example, this is one way I'm trying to wrap it

Why wrapping the Data.Binary.Put monad creates a memory leak? (Part 2)

我是研究僧i 提交于 2019-12-01 17:09:06
问题 As in my previous question, I'm trying to wrap the Data.Binary.Put monad into another monad so that later I can ask it questions like "how many bytes it's going to write" or "what is the current position in file". Before, I thought that understanding why it leaks memory while using a trivial (IdentityT?) wrapper would lead me to solving my problem. But even though you guys have helped me resolve the problem with the trivial wrapper, wrapping it with something usefull like StateT or WriterT

Functions that look pure to callers but internally use mutation

廉价感情. 提交于 2019-12-01 17:01:36
I just got my copy of Expert F# 2.0 and came across this statement, which somewhat surprised me: For example, when necessary, you can use side effects on private data structures allocated at the start of an algorithm and then discard these data structures before returning a result; the overall result is then effectively a side-effect-free function. One example of separation from the F# library is the library's implementation of List.map, which uses mutation internally; the writes occur on an internal, separated data structure that no other code can access. Now, obviously the advantage to this

What was wrong with Control.MonadPlus.Free?

亡梦爱人 提交于 2019-12-01 15:46:20
The free MonadPlus defined as data Free f a = Pure a | Free (f (Free f a)) | Plus [Free f a] was removed in free 4.6 with the following remark ( changelog ): Removed Control.MonadPlus.Free . Use FreeT f [] instead and the result will be law-abiding. What was the problem, in particular, what laws didn't hold? dfeuer According to this issue in the bug tracker the old definition does not obey the associative law. Although I know little about such things, I suspect an other problem is redundancy: Pure a Plus [Pure a] Plus [Plus [Pure a]] ... all seem to represent the same thing. Free structures

The Maybe result from Map.lookup is not type checking with my Monad Transformer stack

删除回忆录丶 提交于 2019-12-01 14:39:50
问题 I am going though the following paper: Monad Transformers Step by Step. In section 2.1 "Converting to Monadic Style", a function is converted to return Value in the Eval1 monad. This part of the function doesn't make sense to me: eval1 env (Var n) = Map.lookup n env The result of that will be Maybe Value however the function's type signature is: eval1 :: Env → Exp → Eval1 Value The function is failing to type check, and the error seems obvious to me. Yet the author specifically states that

What was wrong with Control.MonadPlus.Free?

人盡茶涼 提交于 2019-12-01 14:38:33
问题 The free MonadPlus defined as data Free f a = Pure a | Free (f (Free f a)) | Plus [Free f a] was removed in free 4.6 with the following remark (changelog): Removed Control.MonadPlus.Free . Use FreeT f [] instead and the result will be law-abiding. What was the problem, in particular, what laws didn't hold? 回答1: According to this issue in the bug tracker the old definition does not obey the associative law. Although I know little about such things, I suspect an other problem is redundancy:

How does this State monad code works?

时光总嘲笑我的痴心妄想 提交于 2019-12-01 06:43:48
This code is from this article I've been able to follow it until this part. module Test where type State = Int data ST a = S (State -> (a, State)) apply :: ST a -> State -> (a,State) apply (S f) x = f x fresh = S (\n -> (n, n+1)) instance Monad ST where -- return :: a -> ST a return x = S (\s -> (x,s)) -- (>>=) :: ST a -> (a -> ST b) -> ST b st >>= f = S (\s -> let (x,s') = apply st s in apply (f x) s') data Tree a = Leaf a | Node (Tree a) (Tree a) deriving (Show) mlabel :: Tree a -> ST (Tree (a,Int)) -- THIS IS THE PART I DON'T UNDERSTAND: mlabel (Leaf x) = do n <- fresh return (Leaf (x,n))

Which Monad Transformer to use?

[亡魂溺海] 提交于 2019-12-01 06:40:44
I am trying to write the validate function below so that the validation stops after the first error encountered. The return type of three is different to the other functions. Which monad transformer do I use in order to make this code compile? import scalaz._ import Scalaz._ import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global def one(a : String): Disjunction[Int, String] = a == "one" match { case true => \/-("one") case false => -\/(2) } def two(a : String): Disjunction[Int, String] = a == "two" match { case true => \/-("two") case false => -\/(3) } def

Which Monad Transformer to use?

こ雲淡風輕ζ 提交于 2019-12-01 05:05:37
问题 I am trying to write the validate function below so that the validation stops after the first error encountered. The return type of three is different to the other functions. Which monad transformer do I use in order to make this code compile? import scalaz._ import Scalaz._ import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global def one(a : String): Disjunction[Int, String] = a == "one" match { case true => \/-("one") case false => -\/(2) } def two(a : String

What are the implications of the recursive joining of Promises in terms of Monads?

爱⌒轻易说出口 提交于 2019-12-01 04:12:42
问题 I know that Javascript's promises are technically neither functors nor monads in the sense of Haskell, because (among other things) they include a bind operation that falls back to map when a pure function is passed in (and thus has an ambiguous type) both the Promise constructor and resolve (aka return ) join nested promises recursively The first issue can easily be bypassed by always providing a function with the right type a -> Promise b . The second issue obviously violates the