December 2016 - Libraries

Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary
by Simon Jakobi 25 Feb '17

25 Feb '17

read [1] is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. read's safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither [3], are relatively unknown and too hard to find. To guide users (particularly newcomers) away from read and towards readMaybe and readEither, I propose to 1. Add readMaybe to the Prelude 2. Add readEither to the Prelude 3. Change the documentation for read to point out the partiality and to recommend the above alternatives: The haddocks for read currently read: > The read function reads input from a string, which must be completely consumed by the input process. I propose to add a paragraph roughly like this: > Note: read will throw an error if the parse fails. If there's any uncertainty w.r.t. the shape of the input, readMaybe or readEither should be used instead. Name clashes: A cursory code search on Github for readMaybe [4] reveals many existing definitions, mostly with the same type (Read a => String -> Maybe a) and definition. The same search for readEither [5] shows mostly GHC forks. Design issues: I am somewhat doubtful about the benefit of readEither over readMaybe: While readEither does give additional info on the kind of parse failures, that information is encoded in a String error message, from which it must be parsed if it is needed in the program. As the different parts of the proposal can be implemented independently of each other, please vote separately on each part of the proposal. Discussion period: 4 weeks. Cheers, Simon [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readM… [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readE… [4] https://github.com/search?l=Haskell&q=readMaybe&type=Code [5] https://github.com/search?l=Haskell&q=readEither&type=Code

23 49

MonadZip for Data.Tree
by David Feuer 08 Jan '17

08 Jan '17

MonadZip doesn't really explain how strict mzipWith and (especially) munzip should be. For example, we could have munzip (Node (a, b) ts) = (Node a as, Node b bs) where (as, bs) = Data.List.unzip (map munzip ts) or we could make some or all of the pattern matches lazy, or we could use something lazier than Data.List.unzip, or we could make everything completely spine-strict (surely unwise). Does anyone have a particular preference, or a particular reason to prefer one choice over others? If not, I think we should go with the simple version above. David Feuer

3 4

Proposal: Add NonEmpty constructors to the Prelude
by Yitzchak Gale 05 Jan '17

05 Jan '17

In continuation of Simon Jakobi's proposal for a small incremental change to the Prelude to make it more conducive to partial-function-free programming, https://mail.haskell.org/pipermail/libraries/2016-December/027496.html and after some encouragement from the community on reddit, I propose adding the basic constructors of NonEmpty to the Prelude: nonEmpty, (:|), and the type constructor NonEmpty. In practice, users of NonEmpty will often still need a qualified import of Data.List.NonEmpty. But having the constructors available in the Prelude will make the use of NonEmpty more common, and will make programming without partial functions feel more natural and standard. Note: This proposal is separate from Simon's and should not interfere with the acceptance of Simon's. But it is related in that it attempts to achieve the same goals. Discussion period: Until the end of the discussion period of Simon's proposal. Thanks, Yitz

7 10

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Fwd: Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary
by David Menendez 30 Dec '16

30 Dec '16

On Thu, Dec 29, 2016 at 11:56 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > Read is one of very few classes with stated a deriving technique in the > Haskell Report. > ... > The cure feels a lot worse than any disease. Heck, read isn't even a > member of the class, so this would just spite users and not even address > the symptom raised by this thread. > I may have been unclear. My (weak) preference is to leave things as they are, from an API standpoint, and mention that read is partial in its documentation. I am neutral on deprecation. If at some point the Haskell community decides to refactor the Prelude, it should figure out what Read is for and whether that functionality is essential enough to be in the Prelude. > > -Edward > > > On Thu, Dec 29, 2016 at 11:50 PM, David Menendez <dave(a)zednenem.com> > wrote: > >> On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <spam(a)scientician.net> >> wrote: >> >>> On 2016-12-29 21:12, Andreas Abel wrote: >>> > >>> > I am in favor of deprecating "read" and pointing to a total version in >>> a >>> > library. Otherwise, I'd leave the Prelude unchanged. >>> >> >> This is also my preference. If we *have* to change the Prelude, I’d >> prefer moving Read out entirely. >> >> But that throws a wrench in the works of people who want to be "-Wall" >>> clean... unless you mean "deprecated" in the sense of being *documented* >>> as deprecated rather than actually marked as such (causing deprecation >>> warnings during compilation). >>> >> >> I don't think making life easy for -Wall clean people should be a goal. >> The whole point of warnings is that they indicate things that might not be >> a problem. Otherwise, they’d be errors. This is especially true for >> warnings that only show up if you use -Wall instead of -W. >> >> -- >> Dave Menendez <dave(a)zednenem.com> >> <http://www.eyrie.org/~zednenem/> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/> -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

1 0

Data.Functor.{Product,Sum} functions
by Baldur Blöndal 28 Dec '16

28 Dec '16

Let's see if any of these are useful (a lot more at https://ghc.haskell.org/trac/ghc/ticket/13026) (||||) :: (f a -> b) -> (g a -> b) -> ((Sum f g) a -> b) f |||| g = \case InL fa -> f fa InR ga -> g ga (&&&&) :: (a -> f b) -> (a -> g b) -> (a -> (Product f g) b) (f &&&& g) a = f a `Pair` g a I couldn't think of any for Data.Functor.Compose, names are up for bikeshedding

6 7

Move Data.Functor.Contravariant into base
by Andrew Martin 16 Dec '16

16 Dec '16

The typeclass Contravariant (from the contravariant package) is both useful and fundamental. I would like to see this moved into base. One additional motivating factor is that it would become possible for a DeriveContravariant extension to be written in a future GHC release. I'd love to hear other people's thoughts, even if it's as simple as a yea or nay. Thanks. -Andrew Martin

5 8

Re: Proposal: Expose Coercions for unboxed arrays
by David Feuer 06 Dec '16

06 Dec '16

Richard, there's currently no way to change the roles in different modules, but it's possible to "tunnel" through the roles using Coercions exposed by the defining module (in which the user-provided roles are ignored). On Dec 6, 2016 10:40 PM, "Richard Eisenberg" <eir(a)cis.upenn.edu> wrote: > I don't have an opinion about whether or not David's design is desirable, > but I can comment on implementation feasibility. > > GHC doesn't have a built-in way to have certain roles in some modules and > other roles in other modules. I don't see anything drastically wrong with > such a feature, but it does not currently exist. So to implement David's > suggestion, we would have to have version of these types exposed from some > Unsafe module and then newtypes around each one exposed in the normal > interface. > > Unless someone sees another way, which I may well have missed. > > Richard > > > On Dec 5, 2016, at 2:18 PM, David Feuer <david.feuer(a)gmail.com> wrote: > > > > As discussed in [1], we now have > > > > type role Array nominal representational > > type role IOArray nominal representational > > type role UArray nominal nominal > > type role IOUArray nominal nominal > > type role StorableArray nominal nominal > > type role STArray nominal nominal representational > > type role STUArray nominal nominal nominal > > > > There are good reasons for these, as described in the ticket, but in > > some particular cases, they're overkill. It might be nice to expose > > the representational equivalence locally, with the understanding that > > the user has to ensure that the Ix, Storable, etc., instances are > > compatible. I think the place for these is likely Data.Array.Unsafe, > > although they'd need to be defined in GHC.Arr. For boxed arrays, it's > > sufficient to expose a Coercion between partially applied > > constructors. For unboxed arrays, such a coercion doesn't do much > > (because the element type has a nominal role), so I think only > > Coercions between the fully-applied constructors are really useful for > > those. For STArray and STUArray, I don't *think* we want to expose a > > coercion to change the state thread type; anyone fussing at such a low > > level is probably importing GHC.Arr anyway. > > > > arrayCoercion :: Coercible i j => Coercion (Array i) (Array j) > > ioarrayCoercion :: ... > > > > uarrayCoercion :: (Coercible i j, Coercible a b) => Coercion (UArray i > > a) (UArray j b) > > iouarrayCoercion :: ... > > storablearrayCoercion :: ... > > > > starrayCoercion :: Coercible i j => Coercion (STArray s i) (STArray s j) > > stuarrayCoercion :: (Coercible i j, Coercible a b) => Coercion > > (STUArray s i a) (STUArray s j b) > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/9220 > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

1 0

cabal new-build: what does foo-setup~> mean?
by Ganesh Sittampalam 05 Dec '16

05 Dec '16

Hi, How should I interpret the following dependency solving error from cabal new-build? Resolving dependencies... cabal: Could not resolve dependencies: trying: time-setup.time~>entropy-setup.time-1.1.2.3 (dependency of time-1.1.2.3) trying: time-setup.Cabal~>entropy-setup.Cabal-1.20.0.4 (dependency of time-1.1.2.3) Dependency tree exhaustively searched. FWIW I'm trying to build the HTTP package with GHC 7.0 and the following options. The solver takes ~10 minutes before failing. --constraint 'time==1.1.2.3' --constraint 'entropy<0.2.2.4' -f-warp-tests --constraint 'HUnit<1.4' cabal configure does seem to be able to find a solution. Cheers, Ganesh

2 2

Proposal: Expose Coercions for unboxed arrays
by David Feuer 05 Dec '16

05 Dec '16

As discussed in [1], we now have type role Array nominal representational type role IOArray nominal representational type role UArray nominal nominal type role IOUArray nominal nominal type role StorableArray nominal nominal type role STArray nominal nominal representational type role STUArray nominal nominal nominal There are good reasons for these, as described in the ticket, but in some particular cases, they're overkill. It might be nice to expose the representational equivalence locally, with the understanding that the user has to ensure that the Ix, Storable, etc., instances are compatible. I think the place for these is likely Data.Array.Unsafe, although they'd need to be defined in GHC.Arr. For boxed arrays, it's sufficient to expose a Coercion between partially applied constructors. For unboxed arrays, such a coercion doesn't do much (because the element type has a nominal role), so I think only Coercions between the fully-applied constructors are really useful for those. For STArray and STUArray, I don't *think* we want to expose a coercion to change the state thread type; anyone fussing at such a low level is probably importing GHC.Arr anyway. arrayCoercion :: Coercible i j => Coercion (Array i) (Array j) ioarrayCoercion :: ... uarrayCoercion :: (Coercible i j, Coercible a b) => Coercion (UArray i a) (UArray j b) iouarrayCoercion :: ... storablearrayCoercion :: ... starrayCoercion :: Coercible i j => Coercion (STArray s i) (STArray s j) stuarrayCoercion :: (Coercible i j, Coercible a b) => Coercion (STUArray s i a) (STUArray s j b) [1] https://ghc.haskell.org/trac/ghc/ticket/9220

1 0