February 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

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

Re: Suggestion for bang patterns documentation
by Christian Maeder 27 Feb '09

27 Feb '09

Brian Bloniarz wrote: > I got confused by the GHC documentation recently, I was wondering how > it could be improved. From: > http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html Seeing the rule pat ::= !pat you'll probably want to avoid patterns like: "!!pat", "! ! pat", or "~ ! ~ pat". Even the current http://www.haskell.org/onlinelibrary/exps.html#sect3.17.1 apat -> ~ apat allows "~ ~x". (Note the space!) So maybe a separate non-terminal "bpat" should be used with: bpat -> [~|!] apat (and bpat used within pat). You may also want to exclude "v@ ~(...)" in favor of "~v@(...)". >> A bang only really has an effect if it precedes a variable or wild-card pattern: >> f3 !(x,y) = [x,y] >> f4 (x,y) = [x,y] >> Here, f3 and f4 are identical; putting a bang before a pattern that >> forces evaluation anyway does nothing. Maybe the duality (if it is one) should be added that an irrefutable pattern above would make a difference but not within the let below. > The first sentence is true, but only in settings where the pattern is being > evaluated eagerly -- the bang in: >> f3 a = let !(x,y) = a in [1,x,y] >> f4 a = let (x,y) = a in [1,x,y] > has an effect. Cheers Christian

1 0

Newtype unwrapping in the FFI
by Simon Peyton-Jones 12 Feb '09

12 Feb '09

[This email concerns an infelicity in the FFI spec. I'm directing it primarily to the Haskell Prime mailing list, but ccing the libraries list so that people there know about the thread. I suggest that replies go to Haskell Prime only.] Consider this program (see http://hackage.haskell.org/trac/ghc/ticket/3008) module NT( N ) where newtype N = MkN Int module FFI where foreign import "f" :: N -> IO () Is module FFI OK? It would definitely be OK if N was defined in the module FFI: the FFI spec says that the compiler must automatically unwrap any newtype arguments. http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2 But it's less clear when N is defined in another module *and* its representation isn't exported. The author of NT might believe that because N's representation is hidden, she can change it to, say data N = MkN Int without affecting the rest of the world. But she can't. This is a nasty failure of abstraction. It is, I believe the only way in which a client of a NT could be affected by N's representation, even though that representation is allegedly hidden. (ToDo: check on generalised newtype deriving.) This seems Bad to me. Indeed, the cause of the above bug report is that GHC's implementation assumes that the representation is fully hidden if the constructor is not exported, and does not expose the representation of N even to separately-compiled modules (at least when you are not using -O). But the point here is not what GHC stumbles on but what is supposed to happen. Maybe we should fix it. Proposal: * Clarify the spec to say that a newtype can only be automatically unwrapped if the newtype constructor (MkN in this case) is in scope It happens that a large set of types from Foreign.C.Types, such as CInt and friends, are exported without their constructors, so adopting this new rule would require us to change Foreign.C.Types to expose the representation of CInt and friends. (As it happens, nhc requires this already, so there's some #ifdeffery there already.) Simon

3 3

FFI and fixed-size integer types
by Bulat Ziganshin 10 Feb '09

10 Feb '09

Hello , <citating letter from cafe> >>> After reading an ISO draft for standard C, I found >>> a few types that could be usefull when binding to >>> libraries (these are from <stdint.h>): >>> >>> int8_t, uint8_t, int16_t, uint16_t, int32_t, >>> uint32_t, int64_t, uint64_t i propose to change FFI addendum so that haskell compilers guarantee correspondence between Int16 and int16_t types and so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1