- Libraries - Haskell.org

Discussion: remove the Applicative superclass from Alternative
by David Feuer 07 Nov '14

07 Nov '14

Currently, Applicative is a superclass of Alternative. Unfortunately, the *only* laws for Alternative are the monoid laws. Sensible sets of laws have been proposed in the past, but unfortunately *none* of them cover all the current important instances. Thus we have a rather awkward situation where Alternative is a subclass of Applicative, but there's no real way to take advantage of that fact. There are essentially no useful functions that would end up with signatures that look like p :: (Applicative f, Alternative f) => ... I'm wondering, therefore, what people think of the idea of making Alternative entirely independent—just a version of Monoid with a different kind. class Alternative f where empty :: f a (<|>) :: f a -> f a -> f a A second option would be to go with a Functor superclass for Alternative; that might save some typing over the independent Alternative, and it comes with the free theorem fmap f empty = empty

4 9

asum really needs to go into the Foldable class (or something)
by David Feuer 06 Nov '14

06 Nov '14

The current definition is "biased", using foldr and <|> instead of foldMap and the new Alt. This is a bit awkward in the post-BBP world, but we also don't want to just debias it across the board, because if the Foldable is holding lists, the debiased version will be very bad. More generally, there are a number of Foldable members that are very awkward, pleading for MPTC, because the sane implementations depend on both the container type and the element type. I know we're pushing right up against the deadline for 7.10.1, but the current situation is making me very nervous. David

3 9

add Storable a => Storable (Ratio a) and Storable a => Storable (Complex a) to base
by Carter Schonwald 04 Nov '14

04 Nov '14

Getting those two into base for 7.10 would be quite nice. I think this will mostly impact folks who maintain numerical computing libraries, such as myself, and even then, I think this would be a change well worth having! discussion period 1 week (because I'd like to get it OK'd with plenty of time before the merge window for 7.10 finally closes)

10 22

Proposal: strictify foldl'
by David Feuer 04 Nov '14

04 Nov '14

As Duncan Coutts explains toward the end of http://www.well-typed.com/blog/90/ (which proposes something else I personally *don't* endorse), foldl', the strict foldl, isn't actually strict enough. In particular, it's only conditionally strict in the initial value for the accumulator: foldl' (\_ x -> x) undefined [3] = 3 Why does this matter? Strictness analysis needs to look at (and be able to look at) the function passed to foldl' to determine whether the expression is strict in the initial value. foldl'-as-foldr tends to complicate this sort of analysis already. Proposal: make foldl' unconditionally strict in the initial accumulator value, both in GHC.List and in (the default definition in) Data.Foldable, and make foldr' in Data.Foldable unconditionally strict in the initial value of its accumulator. Specifically, foldl' k z0 xs = foldr (\v fn z -> z `seq` fn (k z v)) id xs z0 would change to foldl' k !z0 xs = foldr (\v fn z -> z `seq` fn (k z v)) id xs z0

5 11

Proposal: Add isSubsequenceOf to Data.List
by Niklas Hambüchen 04 Nov '14

04 Nov '14

Data.List has `subsequences`, calculating all subsequences of a list, but it doesn't provide a function to check whether a list is a subsequence of another list. `isSubsequenceOf` would go into the "Predicates" section (http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-List.html#g:12) which already contains: * isPrefixOf (dual of inits) * isSuffixOf (dual of tails) * isInfixOf With this proposal, we would add * isSubsequenceOf (dual of subsequences) Suggested implementation: -- | `isSubsequenceOf a b`: Checks if a is a subsequence of b. isSubsequenceOf :: (Eq a) => [a] -> [a] -> Bool isSubsequenceOf [] _ = True isSubsequenceOf _ [] = False isSubsequenceOf a@(x:a') (y:b) | x == y = isSubsequenceOf a' b | otherwise = isSubsequenceOf a b Niklas

4 4

Re: Discussion: Arities of <*> and *> for Monad instances
by David Feuer 03 Nov '14

03 Nov '14

To be extremely clear, this is *not* a proposal. I'm trying to get a sense of what the practical ups and downs might be. In both cases there's a potential loss of laziness, albeit a "morally correct" one. In both cases there's a potential change in inlining behavior, for good or ill. I just ran into the question in my latest cleanup binge and wanted to see what people thought.

1 0

Discussion: Arities of <*> and *> for Monad instances
by David Feuer 03 Nov '14

03 Nov '14

http://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Applicative.ht… says that The other methods have the following default definitions, which may be overridden with equivalent specialized implementations: u *> v = pure (const id) <*> u <*> v and If f is also a Monad, it should satisfy ... (<*>) = ap The (potential) trouble is that these have higher arities than is always natural. For example, it would seem reasonable to say (<*>) Just f = fmap f (<*>) Nothing = const Nothing and to replace the default definition of (*>) like so: (*>) a1 = (<*>) (id <$ a1) but these are not strictly equivalent because they have arity 1 instead of arity 2. Would such definitions be be better in some cases? If so, should we weaken the rules a bit?

3 3

Proposal: Make default impls for foldl1 and foldr1 lazier
by David Feuer 02 Nov '14

02 Nov '14

We currently have (in Data.Foldable) foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) and something similar for foldl1. This is strict in the entire spine, unlike the list version, because it has to get all the way to the end of the list before it starts laying down Justs. I propose we change this to the obvious: foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x r = Just $ case r of Nothing -> x Just y -> f x y Since GHC 7.10.1 is fast approaching, I doubt we have the usual two weeks to discuss this, so please speak up as soon as you can if you have concerns.

5 4

Proposal: Add Alternative adapter to Data.Monoid
by David Feuer 01 Nov '14

01 Nov '14

I found myself needing this type in my current overhaul of Data.Foldable, but it seems to be generally useful: newtype Alt f a = Alt { getAlt :: f a } deriving (Eq,Ord,Show,Read,Typeable,Data,Generic,Num,Real, Floating, Fractional, RealFrac, RealFloat, Integral, Enum, Bounded,Ix,Functor,Foldable,Traversable,Applicative, Alternative,Monad,MonadPlus,MonadFix, IsString, IsList) -- The laundry list of derived instances is as recommended by Edward Kmett, who would probably want more added if someone can think of more. Some of them would, of course, need to be derived in other modules. The key instance is this: instance Alternative t => Monoid (Alt t a) where mempty = Alt empty (Alt m) `mappend` (Alt n) = Alt (m <|> n)

6 9

Discussion: adding displayException to Exception class
by Michael Snoyman 31 Oct '14

31 Oct '14

I don't want to make a format proposal yet, just open up discussion on an issue, and see how others feel about it. As I recently commented on this list[1], the Show typeclass is overloaded with multiple meanings (serialization, debug info, and user-friendly data display). The general consensus seems to be that the official semantics for Show should be for serialization (as paired up with Read). However, there's at least one use case in base which explicitly uses Show for non-serialization purposes: the Exception class. All instances of Exception are required to have an instance of Show, but there's no way to actually serialize exceptions generally[2]. So by construction and by practice, the Show instance for Exception is used exclusively for the latter two categories I mentioned (debug info and user-friendly data display). As a result of that, it's quite common[3] to define a Show instance for exception types that is *not* serializable, but rather user friendly. This however seems to contradict what is accepted as good practice in general. I have a possible solution that I'd like to propose as a strawman: add a new method to the Exception typeclass: displayException :: e -> String displayException = show The name is up for debate, but I chose `display` since it seems to already be used elsewhere for user-friendly output. Other possible choices are showException or prettyException. The default implementation will reuse the Show instance, so no user code will be broken by this[4]. In the short term, the only other change I'd recommend is that the default exception handler use `displayException` instead of `show` for printing uncaught exceptions. Longer term, after deprecation cycles, we could consider removing the Show superclass from Exception. Again, this isn't a real proposal (yet), I'm more interested now in what people think about such a change. Michael [1] http://www.haskell.org/pipermail/libraries/2014-October/023957.html [2] Both due to how extensible exceptions work, and due to the lack of a Read superclass. [3] This discussion started when Chris Done and I were working with the tar package, which defines custom renderings for FormatError. I've implemented this same technique in some of my libraries, and I'm sure there are many other examples on Hackage. [4] Barring the standard issue of new identifiers clashing with identifiers defined locally.

17 34