monads

问题 I noticed that Data.UnionFind uses the IO monad to provide pointers via IORefs. I imagine everyone happily calls unsafePerformIO when using it locally in pure code, since the data structure is so well understood, but .. Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO operations? 回答1: Is there a canonical cleaner approach to such data structures? Perhaps a wrapper

问题 I noticed that Data.UnionFind uses the IO monad to provide pointers via IORefs. I imagine everyone happily calls unsafePerformIO when using it locally in pure code, since the data structure is so well understood, but .. Is there a canonical cleaner approach to such data structures? Perhaps a wrapper around IO that makes the inevitable unsafePerformIO less unsafe "looking" by prohibiting most IO operations? 回答1: Is there a canonical cleaner approach to such data structures? Perhaps a wrapper

问题 It's possible to encode various types in the untyped lambda calculus through higher order functions. Examples: zero = λfx. x one = λfx. fx two = λfx. f(fx) three = λfx. f(f(fx)) etc true = λtf. t false = λtf. f tuple = λxyb. b x y null = λp. p (λxy. false) I was wondering if any research has gone into embedding other less conventional types. It would be brilliant if there is some theorem which asserts that any type can be embedded. Maybe there are restrictions, for example only types of kind

问题 This is a general question, not tied to any one piece of code. Say you have a type T a that can be given an instance of Monad . Since every monad is an Applicative by assigning pure = return and (<*>) = ap , and then every applicative is a Functor via fmap f x = pure f <*> x , is it better to define your instance of Monad first, and then trivially give T instances of Applicative and Functor ? It feels a bit backward to me. If I were doing math instead of programming, I would think that I

问题 In the chain documentation you find: Calling chain on a wrapped object will cause all future method calls to return wrapped objects as well. When you've finished the computation, use value to retrieve the final value. So does the chain function create a monad? 回答1: No, not a monad, but a comonad! It turns a function that takes a wrapped object and returns a normal value into a function that both takes and returns a wrapped object. As a Haskell type signature that would be: (Wrapped a -> b) ->

问题 I've been messing with Haskell few days and stumbled into a problem. I need a method that returns a random list of integers ( Rand [[Int]] ). So, I defined a type: type Rand a = StdGen -> (a, StdGen) . I was able to produce Rand IO Integer and Rand [IO Integer] ( (returnR lst) :: StdGen -> ([IO Integer], StdGen) ) somehow. Any tips how to produce Rand [[Int]] ? 回答1: How to avoid the IO depends on why it's being introduced in the first place. While pseudo-random number generators are

问题 Haskell is a pure functional programming language. My question is: What are the advantages and disadvantages of using Haskell to solve problems involving lots of state, for example GUI programming or game programming? Also a secondary question: what methods are there to handle state in a functional way? Thanks in advance. 回答1: I'm going to answer your second question first. There are actually many ways to handle mutable state in Haskell (and other FP languages). First of all, Haskell does

问题 I am attempting to define an API to express a particular type of procedure in my program. newtype Procedure a = { runProcedure :: ? } There is state, consisting of a mapping of IDs to records: type ID = Int data Record = { ... } type ProcedureState = Map ID Record There are three basic operations: -- Declare the current procedure invalid and bail (similar to some definitions of fail for class Monad) abort :: Procedure () -- Get a record from the shared state; abort if the record does not

问题 I recently saw the talks Dead-Simple Dependency Injection and Dependency Injection Without the Gymnastics about DI with Monads and was impressed. I tried to apply it on a simple problem, but failed as soon as it got non-trivial. I really would like to see a running version of dependency injection where a class that depends on more than one value that has to be injected a class that depends on a class that depends on something to be injected as in the following example trait FlyBehaviour { def

问题 I'm attempting to use HSlogger to get some information about my program. So I add the following line to my function import Data.Word import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as L import Data.Bits import Data.Int import Data.ByteString.Parser import System.Log.Logger import System.Log.Handler.Syslog importFile :: FilePath -> IO (Either String (PESFile )) importFile n = do warningM "MyApp.Component2" "Something Bad is about to happen." ... And that works fine,