March 2015 - Libraries

Re: [haskell-infrastructure] wither the Platform
by Gershom B 22 Mar '15

22 Mar '15

Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines. A) Users that sandbox and users that do not. B) Libraries that maintain HP compatibility and libraries that do not. The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes — platform-installed packages being available in sandboxes and causing trouble. However, the current solution we push to new users is lacking in certain ways. In particular, I really don’t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc. Furthermore, it is _very_ important to have some community process to “bless” or suggest some set of packages from the zoo of hackage as the “typical” way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc. Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes. Overall I tend to agree with dons’ comments on the reddit thread (http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) and think the key idea is to preserve _both_ the “one stop installer” aspect of the platform and the “blessed package set” element, but to decouple them from one another. This leads to the following proposals: 1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place. 2) For generic linux point to both ghc and cabal binaries from the core teams. 3) Continue to pick out and list a compatible, “blessed” set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains. 4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes. And of these I have one outstanding question — while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can’t solve that, then the MinGHC approach doesn’t yet provide a strictly better solution. Cheers, Gershom On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale(a)sefer.org) wrote: > Mark Lentczner wrote: > > 1) Abandon the Platform… > > > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > > "essential" libs + tools. Keeps a consistent build layout and installation > > mechanism for Haskell. > > > > 3) Re-conceive the Platform. Take a very minimal install approach, coupled > > with close integration with a curated library set that makes it easy to have > > a rich canonical, stable environment. This was the core idea around my "GPS > > Haskell" thoughts from last September - but there would be much to work out > > in this direction. > > I vote for (3) but in a way that it would *not* be much work. > We should definitely do the Platform, but with much *less* work. > > The most important reason we need the Platform is as > a default selection of quality basic libraries. We should not abandon > that concept. Curated package sets do not replace that - the > Platform is not just packages that build together. Nor do OS > packagers. The platform is a community-wide set of basic default > packages that are mature, well tested, all work together well, > and stable. > > The second most important role of the Platform is a web site > where you can get a clear picture of how to download and install > a default Haskell installation for your platform, and a simple view > of where we are in the parade of releases. That should also continue. > > The hardest work of the Platform was its role as a way to bootstrap a > Haskell installation. That is what made it so hard for HP to keep up > with GHC releases, and what consequently gave people the impression > that HP is always old. That work doesn't need to be done as part of the > Platform anymore. We should leverage other good work people are > doing to create installers, and stop doing it as part of the HP process. > > The most important part of an HP release should be a cabal package > that provides the packages in the platform, at the right versions, with > a specification of the recommended GHC version as a pre-requisite. > > Perhaps we can also provide an HP-branded slick installer for some > platforms that does everything in one click, built as a thin wrapper of > some existing installer. But that should not delay the official release > of an HP version. It's just a nice-to-have extra. > > Once we pare down the work needed for an HP release, we should > release new versions of HP quite often - *more* often than GHC > releases, not less often. > > Another thing we should fix is the (now false) impression that HP > gets in the way of installing other packages and versions due to > cabal hell. We should make "require-sandbox" the default setting > in the cabal config file. I would go further - I would add a cabal > feature to create a sandbox automatically unless "--user" or > "--global" is specified explicitly. I would make "foo installed" a > default constraint (that is easy to override) for all platform packages, > which solves virtually all cabal hell problems (assuming you are > using a sandbox) and will not keep things old if we release often. > > Thanks, > Yitz > _______________________________________________ > haskell-infrastructure mailing list > haskell-infrastructure(a)community.galois.com > http://community.galois.com/mailman/listinfo/haskell-infrastructure >

2 1

Re: wither the Platform
by Mark Lentczner 21 Mar '15

21 Mar '15

Eeek! I really really did mean to make the subject *whither*, not *wither!*

2 1

Proposal: parametrize tree stem container type in containers
by M Farkas-Dyck 19 Mar '15

19 Mar '15

A few years ago I uploaded the package generic-tree to Hackage (before I knew the customary version scheme, sorry about that) which has trees parametrized over stem container type: data Tree v a = Node a (v (Tree v a)) As this is a functional superset of the containers tree, I think it appropriate to include in containers, which I hereby propose. Ultimately, if this is accepted, I would like to define the list-specialized tree in terms of this.

2 1

Proposed significant breaking changes to Win32
by Yitzchak Gale 18 Mar '15

18 Mar '15

There are some discussions going on in this issue: https://github.com/haskell/win32/issues/24 with proposals for extensive breaking changes to the Win32 library. Well over 100 functions would be involved. These changes would finally fix many long outstanding defects in the API, some of which make it impossible to use important Win32 functions in the way originally intended. I would generally support these proposals (after having seen that Neil supports them). But does anyone have any estimate of how much breakage it would cause on Hackage, or in the Windows builds of GHC? Thanks, Yitz

2 1

Expand the Data.Set API
by David Feuer 17 Mar '15

17 Mar '15

There are a few rather conspicuously missing features: 1. A way to take the intersection of a list of sets. This shouldn't really be a big deal, and it already exists for unions, but the intersection version should probably sort the sets by size before folding, or otherwise try to do something smart. 2. A way to insert an element if an == one is not already present (insert replaces an existing one with a new one). Currently, as far as I can tell, this can only be done using either if e `member` s then s else insert e s which potentially descends the tree twice for no reason or s `union` singleton e which is documented as being O(|s|+1), although I wouldn't be shocked if the documentation were too pessimistic in this case. 3. A way to delete an element and simultaneously find out whether it was in the set. David Feuer

8 9

zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_
by M Farkas-Dyck 17 Mar '15

17 Mar '15

Analogs of monadic functions, which likely ought to be in base as part of AMP. I send no patch yet, for I not know which way to do the Data.Traversable <-> Control.Applicative cyclic import. -- | 'filterA' generalizes the list-based 'filter' function. {-# INLINE filterA #-} filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure []) where bool True x = const x bool False _ = id -- | 'mapAndUnzipA' maps its first argument over a list, returning the result as a pair of lists. {-# INLINE mapAndUnzipA #-} mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) mapAndUnzipA f xs = unzip <$> traverse f xs -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. {-# INLINE zipWithA #-} zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] zipWithA f x y = sequenceA (zipWith f x y) -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final result. {-# INLINE zipWithA_ #-} zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () zipWithA_ f x y = sequenceA_ (zipWith f x y) -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. {-# INLINEABLE replicateA #-} {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} replicateA :: (Applicative p) => Int -> p a -> p [a] replicateA n x = sequenceA (replicate n x) -- | 'replicateA_' is like 'replicateA', but discards the result. {-# INLINEABLE replicateA_ #-} {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} replicateA_ :: (Applicative p) => Int -> p a -> p () replicateA_ n x = sequenceA_ (replicate n x)

7 8

Generalizing map?
by Fumiaki Kinoshita 15 Mar '15

15 Mar '15

A dozen of functions like concat, foldr, mapM, have been generalized through BBP. Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so map :: Functor f => (a -> b) -> f a -> f b map = fmap The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

16 18

Proposal: Add (<$>) to Prelude as part of the AMP in GHC 7.10-RC3
by Edward Kmett 10 Mar '15

10 Mar '15

We have a couple of weeks until the third release candidate for GHC 7.10 goes out the door. Along the way with the last couple of release candidates folks have found some problems with the way we implemented the AMP. [1][2] Most notably, we failed to include (<$>) in the Prelude, so the standard idiom of foo <$> bar <*> baz <*> quux doesn't work out of the box! I'd like to include (<$>) in the Prelude in RC3. I'd also like to invite discussion about whether folks believe we should include (<$) out of the box. (<$) has been a member of Functor for a long time, which is only visible if you import it from Data.Functor or bring in Control.Applicative. There is an idiom that you use (<*) and (<$) to point to the parts of the structure that you want to keep the answers from when building longer such Applicative chains. Discussion Period: 2 weeks Thank you, -Edward Kmett [1] http://www.reddit.com/r/haskell/comments/2wzixa/shouldnt_be_in_prelude/ [2] https://plus.google.com/115504368969270249241/posts/URzeDWd7qMp

39 50

Add MonadError () Maybe
by Phil Scott 09 Mar '15

09 Mar '15

With Maybe being isomorphic to Either (), can we have the instance MonadError () Maybe? I'm interested in the MonadError class, and write generic code against it, and would like it to work with Maybe.

3 2

ANNOUNCE: fgl 5.5.1.0
by Ivan Lazar Miljenovic 09 Mar '15

09 Mar '15

I'm pleased to announce that - after being pestered about it for the past few months ;-) - I've released a new version of the Functional Graph Library that should* now be compatible with GHC 7.10. fgl is now developed on GitHub: https://github.com/haskell/fgl * In that I can't test it on my own machines -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0