- Libraries - Haskell.org

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 03 May '14

03 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

16 40

Tightening up on inferred type signatures
by Simon Peyton Jones 30 Apr '14

30 Apr '14

Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn't followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon

6 9

Proposal: Add modify' to Control.Monad.State.Strict
by Niklas Hambüchen 29 Apr '14

29 Apr '14

Code like flip execState 0 (forever $ modify (+1)) leaks memory as hell, and gets fixed by using x <- get put $! x + 1 I propose the addition of modify' to Control.Monad.State.Strict. This seems useful for the strict state monad and is consistent with similar functions in base (such as modifyIORef'). Discussion period: 2 weeks.

10 10

Proposal: Add bifunctor related classes to base
by Dan Doel 29 Apr '14

29 Apr '14

The previous discussion about methods on Either had some mention of adding bifunctors to base, but no one wrote up the details. So I've taken it upon myself to do so. The following proposal is to add some modules of the bifunctors [1] package to base, namely: Data.Bifunctor Data.Bifoldable Data.Bitraversable These modules contain classes and functions for working with types similar to those identified by Functor, Foldable and Traversable, except that there are parameterized by two 'element types' so to speak. The advantages of this change are among the following: These are the right abstractions for many operations. For instance, Arrow is often recommended if someone wants to map over both sides (or the left side) of a pair. In fact, I'd wager that it is the single most common reason for recommending use of Arrow. But this is not really what Arrow was designed to accomplish. This is exactly what Bifunctor is for, though, and it abstracts over this kind of operation with pairs, Either, and in my experience many custom data types. Placement in base gives a better opportunity for people to find these right abstractions. If someone goes into the documentation for Data.Either looking for a way to map both parameters, they will not, of course, be directed to the bifunctors package, even though it provides a good means of doing what they want. If Bifunctor were in base, the documentation for Either would note that it is one. Some things to consider: The API of the modules will shrink a bit due to Applicative becoming a superclass of Monad in 7.10. There is no reason for a separate bitraverse and bimapM and so on. Some things will likely be renamed, as well; bisequenceA => bisequence, for instance. The 'first' and 'second' functions in Data.Bifunctor overlap with Arrow. This actually means that they are a drop-in replacement for the commonly suggested misuse of Arrow. None of the dependencies of the bifunctors package are needed by the modules in question. They are used for other modules, or as part of an arbitrary decision of where to put an instance. For example, the tagged dependency is used to give instances for Tagged, but these could easily be moved into the tagged package if base were to adopt these classes. Discussion period: 2 weeks [1] http://hackage.haskell.org/package/bifunctors

13 16

Show instances missing for Identity?
by John Wiegley 28 Apr '14

28 Apr '14

I'm wondering if there is a reason why this is missing, but if not, I proposed adding the following to Data.Functor.Identity. instance Show a => Show (Identity a) where show (Identity x) = "Identity " ++ show x John

2 1

Split Base
by harry 28 Apr '14

28 Apr '14

There was some talk a while ago about splitting the base package, but I can't find any follow up. Is this still going ahead? Are there any concrete plans? -- View this message in context: http://haskell.1045720.n5.nabble.com/Split-Base-tp5748616.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 1

PVP proposal: no upper bounds on non-upgradeable packages
by Michael Snoyman 27 Apr '14

27 Apr '14

At Herbert's request, I'm splitting off this part of the PVP proposal I made[1] to its own separate proposal. Same discussion period of three weeks. The proposal is: Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code. The purpose (elaborated in my blog post[2]) is that these upper bounds virtually never provide for a successful build. Instead, they are purely about what error messages the user receives. With this change: * Some build plans that would have previously been impossible are now possible, without resorting to the nuclear option of --allow-newers. * Instead of cabal version bound error messages, users get GHC compiler errors that can be fed back upstream to help get packages fixed more expediently. Downsides I'm aware of: * If you consider the cabal error messages more user friendly, then the error message quality goes down. * Users may find out later than they do right now about a failing build. [1] http://www.haskell.org/pipermail/libraries/2014-April/022529.html [2] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp

10 16

ANNOUNCE: fgl-5.5.0.0
by Ivan Lazar Miljenovic 27 Apr '14

27 Apr '14

I'm pleased to announce a new version of the functional graph library: http://hackage.haskell.org/package/fgl-5.5.0.0 The main change in this version: proper Show, Read and Eq instances for both graph implementations. Previously, Data.Graph.Inductive.Tree had a pretty-printed Show output; now both it and PatriciaTree have Show and Read instances via the mkGraph function, and Eq via deriving (I'm not sure how well this will work because as I write this I realise it may not deal with multiple edges that well... I guess I'll be doing an updated version tomorrow after getting some sleep ;p). The previous Show behaviour of Tree is now available as a pretty-printing function for all DynGraph instances. The PatriciaTree implementation is now exported and used by default, because as far as I'm aware it will always perform better. Finally, the Data.Graph.Inductive.Graphviz module has been removed; if you want to visualise your fgl graph, please see my graphviz package on Hackage (cheap plug? moi?). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Proposal: Changes to the PVP
by Michael Snoyman 27 Apr '14

27 Apr '14

I would like to propose the following changes to the PVP. These are the same changes that I recently published on the Yesod blog[1]. For more information on the motivations behind these changes, please see that blog post. 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure reproducible builds of non-published software, but rather to provide for more reliable builds of libraries on Hackage. Reproducible builds should be handled exclusively through version freezing, the only known technique to actually give the necessary guarantees. 2. Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code. 3. We should be distinguishing between mostly-stable packages and unstable packages. For a package like text, if you simply import Data.Text (Text, pack, reverse), or some other sane subset, there's no need for upper bounds. (Note that this doesn't provide a hard-and-fast rule like the current PVP, but is rather a matter of discretion. Communication between library authors and users (via documentation or other means) would be vital to making this work well.) 4. For a package version A.B.C, a bump in A or B indicates some level of breaking change. As an opt-in approach, package authors are free to associated meaning to A and B beyond what the PVP requires. Libraries which use these packages are free to rely on the guarantees provided by package authors when placing upper bounds. (Note that this is very related to point (3).) Discussion period: 3 weeks. [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp

18 49

Upper bounds in PVP WAS: Gearing up (again) for the next release: 2014.2.0.0
by Michael Snoyman 27 Apr '14

27 Apr '14

Starting a separate subject for this response so I don't drive Mark absolutely crazy. On Wed, Apr 9, 2014 at 3:19 PM, Vincent Hanquez <tab(a)snarc.org> wrote: > On 2014-04-08 16:29, Gregory Collins wrote: > > >> >> >> Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the >> Hackage package versioning policy and until this is fixed I think that >> issue precludes it from being included in the platform. >> >> > First of, you might want to read up on the difference between the > definition of policy and rules/law. "obey" doesn't have its place here. > > Second, the tls/crypto ecosystem is following most of the PvP apart from > "3 Dependencies in Cabal". > > Third, The PvP doesn't actually *enforce* any requirements on > dependencies. I can only see CAN, SHOULD, MAY in the section 3. > On the other hand, you can find MUST in section "2 Versions numbers", and > as far I'm concerned the tls/crypto ecosystem is following each > requirements in this section. > > Reading that section myself, I have to say I agree with Vincent's interpretation. It would seem therefore that the packages under question are in fact in compliance with the requirements of the PVP, and therefore there's no blocker to including tls in the platform in the future, regardless of how you interpret the HP's statement "we follow the Haskell Package Versioning Policy". So if someone wants to object to inclusion of tls, it would have to be on technical grounds, rather than simply quoting a document. Michael

10 14