- Libraries - Haskell.org

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

Many functions can be generalised
by Baldur Blöndal 04 Dec '16

04 Dec '16

A year ago Edwardk Kmett pointed out some possible generalizations of functions [1], I made a ticket about them that led me here [2]. In addition to the functions mentioned > maybeToList :: Foldable f => f a -> [a] > maybeToList = toList > catMaybes :: (Foldable f) => f (Maybe a) -> [a] > catMaybes :: (Foldable f, Foldable g) => f (g a) -> [a] > catMaybes = foldMap toList > mapMaybes :: (a -> Maybe b) -> (forall f. Foldable f => f a -> [b]) > mapMaybes :: Foldable m => (a -> m b) -> (forall f. Foldable f => f a -> [b]) > mapMaybes f = foldMap (toList . f) we also have *many* other functions (I do not propose generalising all these function ((especially when the name stops making sense)), but I will include them) that I will define in the vocabulary of ‘lens’. Some generalise to ‘Foldable’ > take :: Int -> (forall f a. Foldable f => f a -> [a]) > take n = toListOf (taking n folded) > drop :: Int -> (forall f a. Foldable f => f a -> [a]) > drop n = toListOf (dropping n folded) > takeWhile :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > takeWhile p = toListOf (takingWhile p folded) > dropWhile :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > dropWhile p = toListOf (droppingWhile p folded) > -- Same as ‘Control.Lens.Indexed.None’ > filter :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > filter p = toListOf (folded.filtered p) > cycle :: Foldable f => f a -> [a] > cycle = toListOf (cycled folded) > lookup :: Eq k => k -> (forall f. Foldable f => f (k, v) -> Maybe v) > lookup = lookupOf folded > listToMaybe :: Foldable f => f a -> Maybe a > listToMaybe = firstOf folded while others — to ‘Traversable’ > transpose :: Traversable f => f [b] -> [f b] > transpose = transposeOf traverse > scanl1 :: (a -> a -> a) -> (forall f. Traversable f => f a -> f a) > scanl1 = scanl1Of traverse > scanr1_ :: (a -> a -> a) -> (forall f. Traversable f => f a -> f a) > scanr1_ = scanr1Of traverse More radical suggestions (pay no heed to the hacky ‘partsOf’, assume better implementation [3]) would allow us to sort a ‘data V2 a = V2 a a deriving (…, Traversable)’ if it contains ordered values: > sort :: (Traversable t, Ord a) => t a -> t a > sort = over (partsOf traverse) Data.List.sort > sortBy :: (a -> a -> Ordering) -> ([a] -> [a]) > sortBy = over (partsOf traverse) . Data.List.sortBy > sortOn :: Ord b => (a -> b) -> ([a] -> [a]) > sortOn = over (partsOf traverse) . Data.List.sortOn > reverse :: Traversable t => t a -> t a > reverse = over (partsOf traverse) Data.List.reverse > -- Based on ‘Control.Lens.??’ > flip :: Functor f => f (a -> b) -> a -> f b > flip f x = fmap ($ x) f or > flip :: (Functor f, Distributive g) => f (g a) -> g (f a) > flip = Data.Distributive.distribute AMP happened some years ago, does this go too far or not far enough? ;) share your thoughts P.s. I understand those skeptical of the ‘partsOf’ solutions but they do feel magical and uses crop up in odd places, especially in compound structures (I don't have better examples): > ghci> peopleList = Pair ["Bob", "Eve"] (Just "Alice") > ghci> data Product f g a = Pair (f a) (g a) deriving (Show, Functor, Foldable, Traversable) > ghci> sort peopleList > Pair ["Alice","Bob"] (Just "Eve") > ghci> reverse peopleList > Pair ["Alice","Eve"] (Just "Bob") > ghci> peopleMap = fromList [(1,"Bob"),(2,"Eve"),(3,"Alice")] > ghci> sort peopleMap > fromList [(1,"Alice"),(2,"Bob"),(3,"Eve")] > ghci> reverse peopleMap > fromList [(1,"Alice"),(2,"Eve"),(3,"Bob")] [1] https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_cha… [2] https://ghc.haskell.org/trac/ghc/ticket/12828 [3] http://stackoverflow.com/a/33320155/165806

8 19

Re: The lazy Show instance for GHC.Generics.U1 is confusing.
by Ryan Scott 28 Nov '16

28 Nov '16

I don't quite understand your objection (what is the value you're showing?). But the Show U1 instance's laziness is deliberate. We designed all of U1's instances to emulate those of Proxy so that in the future, we could unify the datatypes in GHC.Generics with more standard ecosystem definitions (i.e., replace U1 in favor of Proxy, (:*:) with Product, (:+:) with Sum, etc.) See https://ghc.haskell.org/trac/ghc/ticket/11650 for the discussion on this. Ryan S.

1 0

Traversal order newtypes for Data.Tree, and Ord instances
by David Feuer 27 Nov '16

27 Nov '16

Data.Tree.Tree has Foldable and Traversable instances for traversing a tree in preorder. Should we add the derived Ord instance to match? Should we offer newtypes for traversing in post-order and level-order with Eq and Ord instances to match? I've made coercions explicit below, rather than relying on map/coerce rules, to make performance characteristics clearer. deriving instance Ord a => Ord (Tree a) newtype PostOrder a = PostOrder {getPostOrder :: Tree a} deriving (Show, Read, Functor) instance Foldable PostOrder where foldMap f (PostOrder (Node a ts)) = foldMap (foldMap f . PostOrder) ts <> f a instance Traversable PostOrder where traverse f (PostOrder (Node a ts)) = (\ts' a' -> PostOrder (Node a' (coerce ts'))) <$> traverse (traverse f . PostOrder) ts <*> f a instance Eq a => Eq (PostOrder a) where PostOrder a1 ts1 == PostOrder a2 ts2 = (coerce `asTypeOf` map PostOrder) ts1 == coerce ts2 && a1 == a2 instance Ord a => Ord (PostOrder a) where PostOrder a1 ts1 `compare` PostOrder a2 ts2 = ((coerce `asTypeOf` map PostOrder) ts1 `compare` coerce ts2) <> (a1 `compare` a2) newtype LevelOrder a = LevelOrder {getLevelOrder :: Tree a} deriving (Show, Read, Functor) I'm still working out the best ways to perform level-order folds and traversals. One option for Foldable is instance Foldable LevelOrder where foldr c n (LevelOrder (Node a ts)) = a `c` frlof c n ts where frlof :: (a -> b -> b) -> b -> [Tree a] -> b frlof _c n [] = n frlof c n ts = roots where (roots, forest) = uzt c (frlof c n forest) ts uzt :: (a -> b -> b) -> b -> [Tree a] -> (b, [Tree a]) uzt _c n [] = (n, []) uzt c n (Node a fr : ts) = (a `c` n', fr ++ ts') where (n', ts') = uzt c n ts David Feuer

1 0

The lazy Show instance for GHC.Generics.U1 is confusing.
by David Feuer 23 Nov '16

23 Nov '16

I was messing around in GHCi, exploring the generic representation of a particular value. I tried out both case testSequence of IxSequence x -> case from x of M1 (L1 y) -> y and case testSequence of IxSequence x -> case from x of M1 (R1 y) -> y I was initially mystified to see that neither of these produced an error. Surely, I thought, it can't be both L1 and R1! And indeed it can't. But the Show instance for U1 is lazy, so the first test happily printed out M1 {unM1 = U1} even though that is utter nonsense. I propose that U1 simply derive the Show instance to avoid such peculiar behavior. David Feuer

1 0