- Libraries - Haskell.org

Discussion: Strict maps
by David Feuer 23 Dec '14

23 Dec '14

The containers package has Data.Map.Strict and Data.IntMap.Strict, offering functions for handling maps that are strict in the values stored. But these modules are lies, as comments in the source explain: -- API of this module is strict in the keys, but lazy in the values. -- If you need value-strict maps, use "Data.Map.Strict" instead. -- The 'Map' type itself is shared between the lazy and strict modules, -- meaning that the same 'Map' value can be passed to functions in -- both modules (although that is rarely needed). -- Be aware that the 'Functor', 'Traversable' and 'Data' instances -- are the same as for the "Data.Map.Lazy" module, so if they are used -- on strict maps, the resulting maps will be lazy. Yuck. This is not nice. Clearly, the current interfaces need to stay around for compatibility, but I think we should add some unbroken ones too. There are two and a half sane ways to do this: 1. Make strict types that just wrap the lazy ones in newtype wrappers. The benefits: a) They can reuse all the code from Data.Map.Strict or Data.IntMap.Strict, producing tiny little wrapper modules. b) They can support cheap strictToLazy and unsafeLazyToStrict operations (newtype unwrappers/wrappers). c) They support lazyToStrict operations with no significant new code (reusing the NFData code). 2. Make entirely separate strict types. The benefits: a) The code implementing them does not have to be careful to force everything as it goes in, so the strictness is maintained automatically; changes to the code don't need careful strictness auditing. b) Values only need to be forced on insertion, and GHC should be able to recognize that returned values will have been forced. This should speed things up when lookups are common and updates are rare. c) There may (I'm not sure) be more opportunities for GHC to unbox values when their types are known. 2.5. Do both of the above.

4 6

bind :: Monad m => (a -> m b) -> m a -> m b
by Christopher Done 16 Dec '14

16 Dec '14

Is this defined anywhere in base, and if not could it be placed in Control.Monad? I often find myself writing: fmap (mu bar) (foo zot) Then I decide to change the type of x, so instead I want to just write: bind (mu bar) (foo zot) Which is just like fmap but the function can run in the monad. Similar to traverse: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this: mu bar =<<foo zot The name for this function is a no-brainer: bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<) For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap. Even <> has mappend. I don’t hold much hope for this, Haskellers love operators as much as Perl programmers so few on this list will see the value in plain old words, but at least I can link to this email in the archives for future reference. Ciao

20 35

getDirectoryContents without special directories "." and ".."
by Henning Thielemann 13 Dec '14

13 Dec '14

Whenever I call System.Directory.getDirectoryContents, the first thing I do is to filter out "." and "..". Is there a portable and simple way to do this? I even think that "." and ".." should not be part of the result at all, but that's a different discussion.

3 4

PROPOSAL: Add instances to Data.Monoid newtype wrappers
by Sean Leather 13 Dec '14

13 Dec '14

As of base 4.7.0.1, none of the newtype wrappers in Data.Monoid have instances for: - Typeable - Data - Functor It looks like the base library repository has AutoDeriveTypeable, so I presume that takes care of the Typeable instances. It also looks like First and Last now have Functor instances, amongst others. In particular, I would like to add Functor instances for all parameterized types, where applicable (i.e. Dual, Sum, Product). In general, I think we should add whatever other instances make sense. Data came to mind. Others? Discussion period: 2 weeks (or perhaps until after the beginning of the new year) Regards, Sean

8 8

Proposal: move (group|sort)With to Data.List
by amindfv＠gmail.com 11 Dec '14

11 Dec '14

GHC.Exts contains a couple of really useful functions: groupWith :: (Ord b) => (a -> b) -> [a] -> [[a]] sortWith :: (a -> b) -> [a] -> [a] There seems to be no reason why they wouldn't be -- more sensibly -- in Data.List. I propose we move them (and "the" while we're at it). Tom

4 3

MonadPlus instance for WrappedMonad?
by Fumiaki Kinoshita 10 Dec '14

10 Dec '14

Hello, I'm glad that WrappedMonad is Monad since base-4.7.0.0, but I found out that MonadPlus instance is still missing. Is there any reason not to make MonadPlus m => MonadPlus (WrappedMonad m)? Fumiaki

3 2

Proposal: relax type of asProxyTypeOf
by Daniel Wagner 07 Dec '14

07 Dec '14

In base, the new Data.Proxy module has this handy function: asProxyTypeOf :: a -> Proxy a -> a asProxyTypeOf = const This is nice for restricting the phantom type variable of a Proxy that you have lying around. This use could be generalized to other types with phantom type variables by making the type slightly more polymorphic: asProxyTypeOf :: a -> proxy a -> a Since phantom type variables are a very common pattern, this would make asProxyTypeOf more generally useful. Possible downside: it may be that somebody used asProxyTypeOf to restrict both the phantom type and the "Proxy" type, and that the more polymorphic type for asProxyTypeOf would cause that code to break. I find this pretty unlikely. Perhaps the folks behind the "tagged" package could mention whether this complaint ever came up when it made a similar generalization. ~d

2 1

Data.Map.unzip?
by Joachim Breitner 06 Dec '14

06 Dec '14

Hi, did anyone else ever wanted to have a function Data.Map.unzip :: Map k (a, b) -> (Map k a , Map k b) and possibly unzipN for N >= 3? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

6 16

Conversion between STRef RealWorld and IORef
by Wolfgang Jeltsch 03 Dec '14

03 Dec '14

Hi, I need to convert values of types STRef RealWorld a to IORef a in order to attach finalizers to them. For now, I am using GHC.IORef for this. Is there a better way to achieve what I want? All the best, Wolfgang

2 3

Implement `calloc{,Bytes,Array,Array0}` allocators
by Oleksandr Petrov 02 Dec '14

02 Dec '14

Hi everyone, There is a proposal [1] (with implemented revision) to implement zero-initialising versions of malloc{,Bytes,Array,Array0} - Add calloc and callocBytes to Foreign.Marshal.Alloc. - Add callocArray and callocArray0 to Foreign.Marshal.Array. The benefit is that you can allocate required amount of memory and be certain that it will be cleared (set with zeroes) before you use it. Original discussion took a place in `fillBytes` [1] and was publicised on that mailing list [2]. Please share your thoughts. Thank you. [1] https://phabricator.haskell.org/D527 [2] https://phabricator.haskell.org/D461#11541 [3] https://www.haskell.org/pipermail/libraries/2014-November/024251.html -- alex p

6 6