March 2009 - Haskell-prime

[Proposal] Move most of Control.Monad to Control.Applicative
by Thomas Davie 11 Jul '09

11 Jul '09

Hi, Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives. Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible. My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives: mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () sequence :: (Applicative f) => [f a] -> f [a] sequence_ :: (Applicative f) => [f a] -> f () filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () replicateA :: (Applicative f) => Int -> f a -> f [a] replicateA_ :: (Applicative f) => Int -> f a -> f () when :: (Applicative f) => Bool -> f () -> f () unless :: (Applicative f) => Bool -> f () -> f () I may have missed some. Bob

4 6

Outlaw tabs
by Achim Schneider 11 Jul '09

11 Jul '09

I guess everyone knows why. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

11 17

One more 'do' pattern
by Bulat Ziganshin 28 Mar '09

28 Mar '09

Hello haskell-prime, as we know, the following code action x y >>= \v -> do can be shortened to following v <- action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element -> do ... or bracket createDialog destroyDialog $ \dialog -> do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element <-- for list do dialog <-- bracket createDialog destroyDialog do ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 21

Specific denotations for pure types
by Conal Elliott 24 Mar '09

24 Mar '09

I just learned on #haskell that Int has implementation/machine-dependent semantics. I'd always assumed that pure (non-imperative) types have specific denotational models, so that for instance the denotation of something of type Int is either bottom or a (smallish) integer. Since precise & simple denotation is at the heart of how I think about programming, and Haskell is my favorite language, I'm startled and disappointed. I knew we didn't have a denotational semantics for Haskell, but I'd previously assumed it was just a matter of working out the details. Has implementation-independent denotation been discussed for Haskell' ? Thanks, - Conal

8 24

Field labels that do updates
by Ramin Honary 04 Mar '09

04 Mar '09

I have written a couple of small, experimental virtual machines in Haskell, and I always use the State monad with the virtual machine data type as the state. data VM a = VM { getAlpha :: Int , getBeta :: String , getGamma :: a } which is all well and good, but I inevitably end up writing code like this along with it: putAlpha a (VM _ b c) = (VM a b c) putBeta b (VM a _ c) = (VM a b c) putGamma c (VM a b _) = (VM a b c) Its useful because you can just create one monadic function that updates the state and pass one of the "put" functions as a parameter. updateVM :: (x -> VM a -> VM b) -> x -> State (VM b) () updateVM putFunc value = do { state <- get ; put (putFunc value state) } ...some algorithm... do updateVM putAlpha 12 updateVM putBeta "Hello" return somthing But writing the "put" functions become tedious for virtual machines with more fields in their type, especially if you need to add a field to the data type in the future. Could there be syntactic sugar added to generate a list of functions that update the fields of a data type? data VM a = VM { getAlpha/putAlpha :: Int , getBeta/putBeta :: String , getGamma/putGamma :: a } Where the slash operator is optional, but if included in the code will cause the compiler to generate functions of the given names that update those fields. Pros: one more time-saving feature implemented in syntactic sugar. The optional nature of the slash operator would give users a choice of whether or not to use it. Cons: increases complexity of the syntax I couldn't find such a suggestion on the mailing list, but something tells me this idea is too simple to have not been suggested before. Sorry if this is a redundant feature request.

2 1