- Libraries - Haskell.org

fail, MonadFail, or MonadPlus? (was Re: broken Monad Either instance?)
by Evan Laforge 09 Dec '11

09 Dec '11

> With a separate MonadFail class we have 4 options: > > 1) Simply translate to: "e >>= \p -> do{stmts}" instead. This means > pattern match errors are always turned into errors. > > 2) Give all do-expressions a MonadFail constraint. > > 3) Only give do-expressions with pattern bindings a MonadFail constraint. > > 4) Only give do-expressions with pattern bindings with uncomplete > patterns a MonadFail constraint. I'm sure this has been brought up in the many 'fail' discussions that have occurred, but what about MonadPlus and substituting a refuted pattern match with mzero? The only time I've used refutable pattern matches is in a list or parser where something like "'a' <- Parse.char" is convenient. What about pattern matches desugaring as something like tmp <- Parse.char case tmp of 'a' -> { ... rest of do block ... } _ -> mzero Of course that just replaces MonadFail with MonadPlus and how to decide if the extra constraint is needed is still unsolved, but at least it's an already existing class. I originally wanted to ask for uses of 'fail', because I haven't heard of any of those, but then I thought of how I use refutable pattern matches. And then that made me think the way fail takes a String is awkward and weird and none of my refutable matches make use of that fact. Then that made me think reusing MonadPlus's mzero seemed more appropriate.

3 3

Proposal: Move the instances from Control.Monad.Instances into GHC.Base
by Edward Kmett 07 Dec '11

07 Dec '11

I propose that we move the contents of Control.Monad.Instances into GHC.Base where they will be picked up and distributed by the Prelude. Discussion deadline: 2 weeks from now (November 24) == Current State == Control.Monad.Instances is currently the canonical source for the following orphan instances, which involve prelude types, but which were not thought of at the time Haskell 98 was written. instance Functor ((->) r) where fmap = (.)instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) rinstance Functor ((,) a) where fmap f (x,y) = (x, f y)instance Functor (Either a) where fmap _ (Left x) = Left x fmap f (Right y) = Right (f y) == The Issues == When using almost any library, you wind up transitively importing Control.Applicative, which imports Control.Monad.Instances and brings them into scope, so realistically any attempt the user might make to define his own version of these instances is doomed to failure and pain upon linking with the larger Haskell ecosystem. == Proposed Enhancement == Control.Monad.Instances has been around for years, so experienced users have always had access to grab these but the main impact of hiding them in Control.Monad.Instances from a POSIWID<http://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does> perspective is to confuse newbies. The potential impact of just doing this right is less than the impact of changing Num, so I'd say we should just do it, and make Control.Monad.Instances an empty stub that exists just to avoid breaking code, and which can be used to support any other missing instances for Prelude types in the future which _can't_ be merged such as the missing instance Monoid e => Monad ((,) e) where return a = (a, mempty) (w,a) >>= k = (mappend w w', b) where (w',b) = k a which I'll propose separately. This would also let us be less careful about importing Control.Applicative in modules that get fed to the Prelude, which would be an important step in any eventual refactoring of the Monad class hierarchy to include Applicative anyways. -Edward

4 5

broken Monad Either instance?
by Christian Maeder 03 Dec '11

03 Dec '11

Hi, I was surprised to see my code break with ghc-7, due to changed monad instances: With ghc-6.12.3 I have: Prelude> :m Control.Monad.Error Prelude Control.Monad.Error> fail "Bla" :: Either String () Loading package mtl-1.1.0.2 ... linking ... done. Left "Bla" but with ghc-7.0.4 and ghc-7.2.2 I get a fatal exception: *Main> fail "Bla" :: Either String () *** Exception: Bla I always viewed "Either String" as an alternative to Maybe with a failure message. The instance in ghc-7 comes from Control.Monad.Instances: instance Monad (Either e) where return = Right Left l >>= _ = Left l Right r >>= k = k r which indeed uses "error" as default implementation of fail. Is there (supposed to be) an overlapping "instance Monad (Either String)" somewhere else? Any comments (or notes) that I missed? Cheers Christian

10 16

evalList, seqList
by Joachim Breitner 01 Dec '11

01 Dec '11

Dear libraries, I am experimenting with the attached code, where right before the consumption by Vector.fromList, the list is unevaluated, and each element has a small type (a Double), but if left unevaluated before the list is traversed further, will hold on to a rather large portion of memory. I want to use the example in a talk about efficient Haskell next week. After consumption by (unboxed) Vector.fromList, the list has been traversed, but every element in the vector is still a huge thunk, thus holding on to 429MB maximum residency. If I just deepseq the hole list before converting it to a vector, the memory residency becomes 140MB, about what can be expected for a unboxed Vector Double with 3664891 entries plus the [Double] with 3664891 entries. The point of the exercise is to show that we get the best performance by evaluating the list value-strict, i.e. evaluate the head of the list before continuing, but still allowing the GC to remove the part of the list has has already been consumed by fromList, yielding a constant space behavior (not counting the final vector). This is actually motivated by a real-world experience of mine. So if I use this function: valueStrictList :: [a] -> [a] valueStrictList [] = [] valueStrictList (x:xs) = x `seq` (x:valueStrictList xs) before fromList, the maximum residency drops to 67MB, which is pretty good. (58MB is the pure cost of the resulting vector). Now I’d like to get the same result with the standard functions from Control.Seq, instead of rolling my own. I did not look in Control.Parallel.Strategies, as I am not interested in parallelization at this point. So I tried Seq.withStrategy (Seq.seqList Seq.rseq) but this has the same effect as deepseq (140MB), which is probably what was intended, but not what I need. So I did look at Control.Parallel.Strategies and found evalList, which sounds like what I want, but Strat.withStrategy (Strat.evalList Strat.rseq) caused a Stack space overflow, and even using the same function as before, but now from Strategies, i.e. Strat.withStrategy (Strat.seqList Strat.rseq) causes a stack overflow. My questions are: 1. Why is there no evalList in Control.Seq? Should it be there? 2. Why does seqList behave differently in Control.Parallel.Strategies and in Control.Seq? Is that a bug? The example code is attached, and the various options are easily tried out by commenting out the apropriate line. I’m using ghc-7.0.4 and parallel-3.1.0.1, and compiled the code with "-O2". 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/

2 1

ANNOUNCE: data-timeout - 64-bit timeouts of nanosecond precision
by Mikhail Vorozhtsov 01 Dec '11

01 Dec '11

Hi. I grew up tired of counting milliseconds, so I wrote a small library[1] that allows me to specify time units for timeouts and convert between them. The library also provides wrapped versions of 'timeout' and 'threadDelay' functions: > threadDelay $ 1 # Minute + 30 # Second Nanosecond precision seems to be enough for RTS and POSIX calls and it also provides a good range for 64-bit representation: > maxBound :: Timeout 30500 w 3 d 23 h 34 m 33 s 709 ms 551 us 615 ns One thing that might disappoint some people is that I chose unsigned underlying type (Word64), which means that "infinite" timeouts cannot be represented. I think "negative" timeouts essentially are performance warts (a way of packing `Maybe Word63` into Word64) that muddle equality and I recommend using `Maybe Timeout` whenever timeout is optional. [1] http://hackage.haskell.org/package/data-timeout

1 0

Proposal: add Control.Monad.whenJust ∷ (Monad m) ⇒ Maybe α→(α→ m ()) → m ()
by Liyang HU 01 Dec '11

01 Dec '11

This particular pattern crops up a lot for me. Does it for anyone else? I (half-heartedly) propose adding to Control.Monad the following: > -- | A variation of 'when' for 'Maybe a'. > whenJust :: (Monad m) => Maybe a -> (a -> m ()) -> m () > whenJust = flip (maybe (return ())) so that I can write: > whenJust (Map.lookup k m) $ \ a -> do > ... instead of say: > case Map.lookup k m of > Nothing -> return () > Just a -> do > ... which is not only nicer on the eyes, but also saves me a valuable level of indentation. Discussion period: 2 weeks. Cheers, /Liyang

5 7

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