- Libraries - Haskell.org

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

03 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 03 Nov '14

03 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 02 Nov '14

02 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 02 Nov '14

02 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 01 Nov '14

01 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 31 Oct '14

31 Oct '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 30 Oct '14

30 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

Proposal: remove versionTags from Data.Version
by Thomas Miedema 29 Oct '14

29 Oct '14

Version in Data.Version from base is defined as: data Version = Version { versionBranch :: [Int], versionTags :: [String] } instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 ## Proposal Remove the `versionTags` field from this type. ## Motivation * The Eq and Ord instances of Version don't agree whether two versions with different versionTags are equal or not [1]: > a = Version [1] ["a"] > b = Version [1] ["b"] > compare a b EQ > a == b False * The Package versioning policy does not include version tags [2]. * Cabal no longer supports package version tags [3,4]. Discussion period: 2 weeks. Note: this is not a proposal to ignore trailing zeros when comparing versions. Neither is this is a proposal to change the Eq instance for Version to only consider the versionBranch field. This is a proposal to remove versionTags altogether. [1] https://ghc.haskell.org/trac/ghc/ticket/2496 [2] http://www.haskell.org/haskellwiki/Package_versioning_policy [3] https://github.com/haskell/cabal/issues/890 [4] http://www.haskell.org/cabal/users-guide/developing-packages.html#package-n…

4 5

Proposal: make nubBy obey the 98 report semantics
by Thomas Miedema 29 Oct '14

29 Oct '14

The implementation of nubBy in Data.List is as follows, where USE_REPORT_PRELUDE refers to [1]: #ifdef USE_REPORT_PRELUDE nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) #else nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a -> a -> Bool) -> a -> [a] -> Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs #endif That comment is actually not correct [2], and the report version and the base version don't have the same semantics when used on asymmetric relations: MyReportPrelude> nubBy (<) [1] [1] Data.List> nubBy (<) [1,2] [1,2] ## Proposal Make nubBy and nub obey the report semantics by swapping the arguments to `eq` in elem_by, and defining nub as nubBy (==). This is the 'still easy' variant from [3]. ## Motivation The Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. See [4,5] for user bug reports. Discussion period: 2 weeks Code review: https://phabricator.haskell.org/D238 [1] https://www.haskell.org/onlinereport/list.html#sect17.6 [2] https://ghc.haskell.org/trac/ghc/ticket/2528 [3] https://ghc.haskell.org/trac/ghc/ticket/7913#comment:3 [4] https://ghc.haskell.org/trac/ghc/ticket/3280 [5] https://ghc.haskell.org/trac/ghc/ticket/7913

4 4

ANNOUNCE: Hasql: A minimalistic general high level API for relational databases
by Nikita Volkov 28 Oct '14

28 Oct '14

This library takes a mission of upgrading the experience of dealing with relational databases in Haskell. It’s robust, it’s API is very concise, yet it’s packed with powerful features like the following: - An abstraction over transactions, which provides an automated resolution of conflicts. The API ensures that you’re only able to perform a specific set of actions in the transaction context, which allows Hasql to safely resolve conflicting transactions by automatically retrying them. This is much inspired by STM and ST. - Support for cursors. Allows to fetch virtually limitless result sets in a constant memory using streaming. - Employment of prepared statements. Every statement you emit gets prepared and cached. This raises the performance of the backend. - Automated management of resources related to connections, transactions and cursors. - A built-in connections pool. - Type-level generation of templates. You just can’t write a statement with an incorrect number of placeholders. - Mapping to any types actually supported by the backend. For a basic tutorial and a demonstration please visit the following link: https://github.com/nikita-volkov/hasql/blob/master/demo/Main.hs Also please join the main discussion thread accompanying the release: http://www.reddit.com/r/haskell/comments/2kkhgo/announce_hasql_a_minimalist…

1 0