November 2011 - Libraries

Proposal: Use time rather than old-time in directory
by Ian Lynagh 16 Sep '14

16 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 27 Apr '12

27 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

Improve System.Environment haddocks
by Gwern Branwen 07 Feb '12

07 Feb '12

17:52:34 < goodgrue> Is there a way to change the environment variables associated with Xmonad.Prompt.Shell at runtime? e.g. I'd like to be able to modify $http_proxy and have that affect subsequently launched processes. 17:55:31 < gwern> goodgrue: that'd be kind of hard. you could prepend a mpodification of $HTTP_PROXY to each command 17:56:10 < gwern> ideally you'd modify xmonad's own environment 17:56:33 < goodgrue> gwern: yeah, the latter is what I was thinking of. is that possible? 17:57:08 < gwern> shell uses `getEnv` from System.Environment but there's no setEnv! 17:57:21 < gwern> if there were, you could probably bind it to a key and use a prompt 17:58:44 < goodgrue> Hm...sounds like this may be a nice piece of missing functionality. is there any reason you can think of that i wouldn't be able to implement setEnv myself? 17:59:04 < gwern> http://hackage.haskell.org/trac/ghc/ticket/3587 17:59:14 < gwern> looks like 'putEnv' may be the real name -- gwern http://www.gwern.net

2 3

Proposal: add 'state' to the MonadState class
by Twan van Laarhoven 21 Jan '12

21 Jan '12

Hello list, Currently the 'state' function is only defined for the State type (aka StateT Identity): state :: (s -> (a, s)) -> State s a state f = StateT (Identity . f) But this function makes sense for all MonadState instances. I therefore propose to either add it to the MonadState class: class MonadState s m | m -> s where ... state :: (s -> (a,s)) -> m a state f = do s <- get let (a,s') = f s set s' return a or as a stand alone function like modify. I personally prefer to add it to the class, since that allows for a more efficient implementation. In particular: instance Monad m => MonadState s (StateT s m) where .... state = StateT (return . f) Discussion period: 2 weeks (ends October 10th) Twan

6 10

Proposal to incorporate Haskell.org
by Don Stewart 16 Dec '11

16 Dec '11

Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) ------------------------------------------------------------------------ = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) <http://conservancy.softwarefreedom.org/>. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence <http://www.opensource.org/licenses/alphabetical>. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium <http://www.haskell.org/haskell-symposium/> and Industrial Haskell Group<http://industry.haskell.org/> webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation "The Haskell Foundation" was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed "community.haskell.org" in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation

4 5

Minor containers API changes
by Milan Straka 09 Dec '11

09 Dec '11

Hi everyone, I have several containers API changes propositions. First five are an attempt to unify the API of different structures. The documentation states IntMap is Map replacement and IntSet is Set replacement, but there are several shortcomings: 1) `{Map,Set}.deleteMin empty` return `empty` `{IntMap,IntSet}.deleteMin empty` trigger `error "Cannot delete in empty..."` Solutions: (a) make `{Map,Set}.deleteMin empty` throw error (b) make `{IntMap,IntSet}.deleteMin empty` return empty I vote for (b), because (a) could cause unexpected runtime errors. Additionally, I expect very little programs depend on `{IntMap,IntSet}.deleteMin empty` causing runtime error. 2) `Map.deleteFind{Min,Max}` has type `Map k a -> ((k,a),Map k a)` `IntMap.deleteFind{Min,Max}` has type `IntMap a -> (a, IntMap a)` Solutions: (a) make the Map variant return only values (b) make the IntMap variant return both key and value I vote for (b), because it generalizes the original functionality. 3) `Map.update{Min,Max}` is given a function of type `(a -> Maybe a)` `Map.update{Min,Max}WithKey` is given a function of type `(key -> a -> Maybe a)` `IntMap.update{Min,Max}` is given a function of type `(a -> a)` `IntMap.update{Min,Max}WithKey` is given a function of type `(key -> a -> a)` Solutions: (a) the Map variants would get a function of type `[key -> ] a -> a` (b) the IntMap variants would get a function of type `[key -> ] a -> Maybe a` I vote for (b), because it generalizes the original functionality. 4) The functions `mapKeys :: Ord k2 => (k1->k2) -> Map k1 a -> Map k2 a` `mapKeysWith :: Ord k2 => (a -> a -> a) -> (k1->k2) -> Map k1 a -> Map k2 a` `mapKeysMonotonic :: (k1->k2) -> Map k1 a -> Map k2 a` have no IntMap correspondents. Both `mapKeys` and `mapKeysWith` can be defined by the user without loss of performance. Solutions: (a) deprecate the `mapKeys*` methods from Map (b) add the `mapKeys*` methods to IntMap. I vote for (a). These methods are all trivial compositions and all but all mapKeysMonotonic are defined as such. For mapKeysMonotonic, a trivial composition with the same asymptotic complexity exists. Also, if these were added to IntMap, none of them would have better performance then user-defined methods. 5) `toDescList` exists in Map, but not in IntMap, Set or IntSet. Solutions: (a) deprecate `Map.toDescList` (b) add `toDescList` to IntMap. In this case, we should consider adding it also to Set and IntSet. I have no strong opinion here. The `toDescList` can be trivially expressed as left fold. But it is currently a subject to list fusion. To vote for (a). Several other changes follow: 6) Result of discussion around http://hackage.haskell.org/trac/ghc/ticket/5242 Add `Map.fromSet :: (key -> a) -> Set key -> Map key a` `IntMap.fromSet :: (Int -> a) -> IntSet -> IntMap a` The implementation would exploit same structure of map and set (leave the shape of the original tree/trie, just adding values). Cons: fromSet is a trivial composition: fromSet f = Map.fromDistinctAscList . map (\k -> (k, f k)) . Set.toAscList This can be defined by the user and is asymptotically optimal. Pro: performance. Also the performance of keysSet would improve, if the map can use data constructors of set. I vote for adding these methods. 7) Improve the generality of intersectionWith. Currently the Map and IntMap define intersectionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c intersectionWithKey :: Ord k => (k -> a -> b -> c) -> Map k a -> Map k b -> Map k c But the combining function is not general enough. Consider two IntMaps storing hashable elements as (hash(element), element). When intersecting elements with the same hash, the intersection can be empty. I propose to change the type of these methods to intersectionWith :: Ord k => (a -> b -> Maybe c) -> Map k a -> Map k b -> Map k c intersectionWithKey :: Ord k => (k -> a -> b -> Maybe c) -> Map k a -> Map k b -> Map k c (and appropriately for IntMap). Note that the combining function of differenceWith already has type `(a -> b -> Maybe a)`. Discussion period: 2 weeks Cheers, Milan PS: Sorry for the long email.

17 40

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

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