November 2011 - Libraries

A Down newtype in Data.Ord?
by Daniel Peebles 29 Nov '11

29 Nov '11

I noticed that the Down newtype (whose Ord instance inverts its payload's ordering) currently only exists in GHC.Exts, and it seems like something fairly generally useful. What do people think of moving it to (or re-exporting it from) Data.Ord? Moving it would be nicer, but the fancy list comprehension desugaring might want it in GHC.Exts, so I'm not sure what the consequences would be. Anyone have comments/ideas? Thanks, Dan

16 28

os.path.expanduser analogue
by Ben Gamari 22 Nov '11

22 Nov '11

On the whole, the filepath package does an excellent job of providing basic path manipulation tools, one weakness is the inability to resolve "~/..." style POSIX paths. Python implements this with os.path.expanduser. Perhaps a similar function might be helpful in filepath? Cheers, - Ben Possible (but untested) implementation expandUser :: FilePath -> IO FilePath expandUser p = if "~/" `isPrefixOf` p then do u <- getLoginName return $ u ++ drop 2 p else return p

3 4

Documentation in Control.Monad.STM.TMVar - isEmptyTMVar
by Heinrich Apfelmus 22 Nov '11

22 Nov '11

Hello, As of stm-2.2.0.1, the documentation for the isEmptyTMVar function [1] reads isEmptyTMVar :: TMVar a -> STM BoolSource Check whether a given TMVar is empty. Notice that the boolean value returned is just a snapshot of the state of the TMVar. By the time you get to react on its result, the TMVar may have been filled (or emptied) - so be extremely careful when using this operation. Use tryTakeTMVar instead if possible. This being software transactional memory, where everything is wrapped into a call to the atomically function, I believe that the second paragraph is now completely obsolete, to the point of being misleading (it sure scared me). I would be relieved if someone could remove it. Most likely, it was originally copied directly from the corresponding documentation of Control.Concurrent.MVar . [1]: http://hackage.haskell.org/packages/archive/stm/2.2.0.1/doc/html/Control-Co… Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

4 4

Need principled approach to strictness properties in Data.Map.Strict
by Johan Tibell 20 Nov '11

20 Nov '11

Hi all, After trying to document the strictness properties of the new Data.Map.Strict module, which is meant to provides a value strict version of the Data.Map API, I feel less sure about our prior decision to make all functions strict in value arguments (even though I was the main proponent). The documentation I ended up with in Data.Map.Strict was: Strictness properties ===================== This module satisfies the following strictness properties: 1. Key and value arguments are evaluated to WHNF; 2. Keys and values are evaluated to WHNF before they are stored in the map. Here are some examples that illustrate the first property: insertWith (\ old new -> old) k undefined m == undefined delete undefined m == undefined Here are some examples that illustrate the second property: map (\ v -> undefined) m == undefined -- m is not empty mapKeys (\ k -> undefined) m == undefined -- m is not empty More than one person said the distinction between (1) and (2) isn't clear and someone else felt that the extra (1) is unnecessary (for values). We definitely want (2): it's the property that ensures that the map never contains any thunks (if we also guarantee that the map is also spine strict). This property eliminates the space leaks that people sometimes run into. This property is the raison d'etre for the Data.Map.Strict module. I would like to settle the strictness properties of Data.Map.Strict once and for all. I would prefer to find a principled reason for the resulting decision or, if I can't have that, I want to lay out all the pros and cons and then make a decision. I think this issue is important, as we're likely to see more modules that help the users get a hold on evaluation order in the future. For reference, here are the arguments I used to argue for having functions be strict in value arguments last time we discussed this: ## Ease of reasoning about evaluation order I felt that being consistently strict would it make it easier to reason about the space usage/evaluation order of code that use the API. Without the extra strictness there are degenerate cases that can catch people off guard. For example, insertWith (\ old new -> if old == maxValue then old else new + 1) k v m is lazy in 'v' because there's a rare case (old == maxValue) where 'new' isn't evaluated. Another potential benefit: in f :: Int -> Int -> Int -> Int f x y z | x == y = z | otherwise = 1 you can rely on == being strict in both arguments and avoid putting redundant bang on x and y (assuming that you want them strict). I was hoping that making all function value strict would enable similar reasoning where Data.Map.Strict is used. ## Constant factor performance improvements We already have (1) for keys in Data.Map. It's an important optimization as it allows us to keep the key unboxed in loops. Consider: lookup :: Ord k => k -> Map k a -> Maybe a lookup = go where go !_ Tip = Nothing go k (Bin _ kx x l r) = case compare k kx of LT -> go k l GT -> go k r EQ -> Just x {-# INLINABLE lookup #-} This function is strict in the key argument, even though the first case alternative doesn't use it. This allows us to compile the inner loop to go :: Int# -> Map Int Int -> Maybe Int go k# m = case m of Tip -> Nothing (Bin _ kx x l r) -> case kx of I# kx# -> case <# k# kx# of True -> go k# l ... when lookup is specialized for some unboxable key type (here: Int). This is a performance win. There's a small (or even tiny) potential performance win in having strict value arguments. Given insertWith :: Ord k => (v -> v -> v) -> k -> v -> Map k v -> Map k v insertWith = go where go _ !k def Tip = def `seq` Bin 1 k def Tip Tip go f k def (Bin sz ky y l r) = case compare k ky of LT -> balanceL ky y (go f k x l) r GT -> balanceR ky y l (go f k x r) EQ -> let x = f x y in x `seq` Bin sz k x l r {-# INLINEABLE insertWith #-} and some call site ...let v = ... in v `seq` insertWith (+) k v m... v will end up being evaluated twice, once at the call site and once inside insertWith. If insertWith was strict in the value argument the evaluation at the call site could perhaps be avoided (Simons?). A second, perhaps even more theoretical, possible optimization we could do is this: If we could specialize the runtime representation of Map to have unboxed keys and value (using e.g. associated data types), then we could write more allocation free functions. For example: findWithDefault :: Ord k => k -> v -> Map k v -> v findWithDefault = go where go !_ !def Tip = def go k def (Bin _ kx x l r) = case compare k kx of LT -> go k def l GT -> go k def r EQ -> x {-# INLINABLE findWithDefault #-} specialized for Ints (and thus Int#) could (using a w/w transformation) take def as an Int# and return it (or the found) value as an Int#. We don't really know how to do this well in practice so this remains a theoretical benefit, for now. Thoughts? Cheers, Johan

5 5

Functor instances for GetOpt data types
by Henning Thielemann 20 Nov '11

20 Nov '11

I propose to add Functor instances for data types in GetOpt as shown below. I like to have them since I want to build an Option record from sub-records for specific functions, and I like to glue together the sub-records and according argument descriptions. With the Functor instance I can lift the option descriptions for the sub-records to the main Option record. As an interim solution I could prepare a package that provides these instances as orphan instances and has a cabal switch to export the instances from base, once they appear there. Discussion period until 4th of December. PS: I am scared by the idea to have to compile the whole GHC only in order to get 'base' built, and then insert and test these Functor instances. Is there an easier way? PSS: Is it necessary to have GetOpt in base? ---------------------------------- instance Functor ArgOrder where fmap f order = case order of RequireOrder -> RequireOrder Permute -> Permute ReturnInOrder g -> ReturnInOrder $ f.g instance Functor ArgDescr where fmap f d = case d of NoArg a -> NoArg $ f a ReqArg g str -> ReqArg (f.g) str OptArg g str -> OptArg (f.g) str instance Functor OptDescr where fmap f (Option short long arg help) = Option short long (fmap f arg) help

2 1

Can the in-progress ByteString proposals make it into GHC 7.4.1?
by Herbert Valerio Riedel 17 Nov '11

17 Nov '11

Hello GHC HQ, According to the GHC Status October 2011 Report[3], the GHC 7.4 branch is supposed to be in "feature freeze" by now. Does this affect/include the bytestring library (as it happens to be a GHC-boot library) as well? More specifically, if the ongoing proposals "Add {to,from}Strict conversion functions between strict and lazy ByteStrings"[1] and "Add NFData instances for strict and lazy ByteStrings"[2] succeed, what's the next stable GHC release they're gonna be included in? [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16444 [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/16397 [3]: http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11 -- hvr

4 6

Proposal: Ignore sub-minor version components in package id
by Joachim Breitner 15 Nov '11

15 Nov '11

Hi, I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them. By the package versioning policy, if the API stays the same, these version numbers stay identical. And if the change does not affect the ABI, the hash stays the same. This would allow upgrades of the package without having to re-build everything depending on it. And if the maintainer does not fully follow the PVP, then it is not a big deal either; the hash will change and Cabal will enforce rebuilds. One could argue that the version can be removed entirely from the package id, but it helps the human reader when looking at the "depends" field of a package. Greetings, Joachim -- Joachim "nomeata" Breitner mail(a)joachim-breitner.de | nomeata(a)debian.org | GPG: 0x4743206C xmpp: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/

5 10

Addition to unix: raw ByteString APIs
by Simon Marlow 14 Nov '11

14 Nov '11

I propose to commit the attached patch to the unix package and release it with GHC 7.4.1. The commit log is reproduced below. Comments please! The unix version number will of course be bumped appropriately. Cheers, Simon commit d5e43be90d3c6f8869dd2b0c65800c9a6dd0ac70 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Fri Nov 11 16:18:48 2011 +0000 Provide a raw ByteString version of FilePath and environment APIs The new module System.Posix.ByteString provides exactly the same API as System.Posix, except that: - There is a new type: RawFilePath = ByteString - All functions mentioning FilePath in the System.Posix API use RawFilePath in the System.Posix.ByteString API - RawFilePaths are not subject to Unicode locale encoding and decoding, unlike FilePaths. They are the exact bytes passed to and returned from the underlying POSIX API. - Similarly for functions that deal in environment strings (System.Posix.Env): these use untranslated ByteStrings in System.Posix.Environment - There is a new function System.Posix.ByteString.getArgs :: [ByteString] returning the raw untranslated arguments as passed to exec() when the program was started.

9 11

ANNOUNCE: iteratee-compress 0.3.0.0
by Maciej Marcin Piechotka 13 Nov '11

13 Nov '11

Iteratee-compress provides compressing and decompressing enumerators including flushing (using John Lato's implementation). Currently only gzip and bzip is provided but LZMA is planned. Changes from previous version: - Move API from enumerator to enumeratee Next goals: - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing Regards

1 0

Proposal: Add the orphan instance Monoid e => Monad ((, )e) to Data.Monoid
by Edward Kmett 12 Nov '11

12 Nov '11

I propose adding an (orphan) instance of Monad for ((,) e) to Data.Monoid. Discussion deadline: 2 weeks from now (November 26) == Current State == No instance == The Issues == Control.Applicative already exports a compatible instance for Applicative for ((,) e), but there isn't a canonical place to get the compatible Monad. == Proposed enhancement == Add the following orphan instance to Data.Monoid. instance Monoid e => Monad ((,) e) where return a = (a, mempty) (w,a) >>= k = (mappend w w', b) where (w',b) = k a Why? Monoid isn't exported from the Prelude, so there is currently no place for this instance to live currently that doesn't render it an orphan. == Alternative == We could place this instance in Control.Monad.Instances which is where we've placed similar instances in the past. However, this would increase the likelihood of failure to properly import the instance for users, who would have to know to import both Data.Monoid and Control.Monad.Instances, rather than just Data.Monoid. Moreover in a separate active proposal I've just proposed moving all the Control.Monad.Instances instances out, so in the event that that proposal is adopted this would be unsatisfyingly the only instance there. -Edward

6 6