- Libraries - Haskell.org

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

Proposal: Add a strictly accumulating scanl' to Data.List
by David Feuer 28 Oct '14

28 Oct '14

Joachim Breitner wrote, in https://ghc.haskell.org/trac/ghc/ticket/9345#comment:6, a strictly accumulating version of scanl, to be named scanl'. I was initially concerned about its safety for fusion, but am now convinced of its correctness and believe it should be added to Data.List. scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f a bs = build $ \c n -> a `seq` a `c` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `c` g b'))) (\b -> b `seq` n) bs a

3 3

Call-for-help: Add XDGBDS support to `directory` package
by Herbert Valerio Riedel 25 Oct '14

25 Oct '14

Hello *, I'd like to invite everyone with knowledge of the XDG Base Directory Specification[1] to contribute to https://github.com/haskell/directory/issues/6 >From what I gathered, it appears to me that adhering to the XDGBD Spec (on Linux at least) is desirable and "strongly encouraged" by Linux distributions[2], so I think this ought to be implemented sooner rather than later (maybe even in time to be part of GHC 7.10.1) This issue was originally filed against GHC, since it affects the location of the `~/.ghc` folder (and fwiw this would also affect cabal's `~/.cabal` folder location). Thanks, hvr [1]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2]: https://wiki.debian.org/XDGBaseDirectorySpecification

1 0

Proposal: Let OpenGL depend on the StateVar package
by Edward Kmett 24 Oct '14

24 Oct '14

We're currently actively working on writing better SDL 2 bindings in sdl2. For various reasons, it can't depend on the OpenGL package directly, but it needs a state variable construction. Sadly, not every platform with SDL 2 has OpenGL -- thanks Microsoft. We'd like to depend on the StateVar package, but then we'll get two versions of the notion of a StateVar that conflict. By *far* the cleanest option for us moving forward would be if OpenGL switched to using the externalStateVar package that you also maintain, then we could incur a dependency on that. I realize that when this was last proposed there was some pushback from the Haskell Platform, but otherwise what we're going to start seeing is a profusion of almost-compatible APIs, which is the very thing that the Haskell Platform is meant to prevent. This would necessitate adding StateVar to the Haskell Platform, as OpenGL is in the Haskell Platform. The package is maintained by the same maintainer as the current OpenGL package. Discussion Period: 2 weeks -Edward Kmett

9 14

[PROPOSAL] Adding Generics-based DefaultSignature to `deepseq` package
by Herbert Valerio Riedel 24 Oct '14

24 Oct '14

The Proposal ============ I hereby propose to merge `deepseq-generics`[2] into `deepseq`[1] in order to add Generics support to the `NFData` class based on the `-XDeriveGenerics` and `-XDefaultSignature` language extensions. A concrete patch is available for bike-review at [3] Prior Proposal & What's changed =============================== About 2 years ago, I already proposed something similar[4]. Back then the major concern was avoiding a conditionally exported API as using the (back then) rather young `Generics` extension would leave the Haskell98 domain. This lead to me release Generics support as a companion package[2] which turns out to have become a rather popular package (judging from the Hackage download-count stats). I only realized after the discussion was effectively finished, that having a separate `deepseq-generics` actually does have an IMO non-neglectable downside: You can't support a `DefaultSignature`-based default implementation, as those need to be backed into the `NFData` class. Missing out on `DefaultSignature` would be a shame IMO, because * There's a chance that starting with GHC 7.10 `deriving` may work for arbitrary classes[5], putting `NFData` on equal footing as built-in classes such as `Eq` or `Show`. Specifically, you would be able to write data Foo = Foo [Int] String (Bool,Char) | Bar (Maybe Char) deriving (Show, Generic, NFData) instead of having to manually write the following boilerplate instance NFData Foo where rnf (Foo x y z) = rnf x `seq` rnf y `seq` rnf z rnf (Bar x) = rnf x which gets tedious rather soon if you have many (and more complex) types and tend to refactor regularly (with a risk of failing to adapt your manual instances if you change the strictness of fields) * The current default `rnf` implementation, i.e. rnf a = a `seq` () is rather error-prone, as it's *very* easy to end up with an incorrect instance. Especially after refactoring a type for which the NF=WHNF assumption was broken after refactoring by adding new fields, or changing the strictness of existing fields. The Generics-derived `rnf` implementation does not have such a problem. Moreover, popular packages are starting adopt (and even recommend) the use of Generics in combination with `DefaultSignature` to provide automatically derived default instances, most notably `hashable`[6], `binary`[7], or `aeson`[8] just to name a few. In addition to providing a precedence for the use of Generics, I consider those packages evidence for Generics to have proven itself to the point of replacing TemplateHaskell in these use-cases. Compatibility & Breakage Considerations ======================================= * This change requires a major version bump to deepseq-1.4.0 * `deepseq` needs to drop GHC 7.0.* support as GHC 7.2 is the first version to support Generics & `DefaultSignature`. * Code relying on the current `rnf` default-implementation will most likely break (unless a `Generics` instance happens to be in-place) However, it's easy to provide forward/backward-compatibility w/o any CPP, by simply explicitly defining instance NFData XYZ where rnf = seq x () Discussion Period: 2 weeks [1]: http://hackage.haskell.org/package/deepseq [2]: http://hackage.haskell.org/package/deepseq-generics [3]: https://github.com/haskell/deepseq/pull/1 [4]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/17940 [5]: https://ghc.haskell.org/trac/ghc/ticket/5462 [6]: http://hackage.haskell.org/package/hashable [7]: http://hackage.haskell.org/package/binary [8]: http://hackage.haskell.org/package/aeson

9 12

Proposal: Add foldrWithIndex and foldlWithIndex to Data.List
by David Feuer 23 Oct '14

23 Oct '14

These functions can be lifted pretty much straight out of Data.Sequence. In particular, foldrWithIndex makes for a particularly nice expression of a fusing findIndices function, as is present in Data.Sequence.

5 9

Future of "Text.Show.Functions" module
by Herbert Valerio Riedel 23 Oct '14

23 Oct '14

Hello *, I noticed the following module (trimmed for brevitiy) hiding in `base`: -- This module deliberately declares orphan instances: {-# OPTIONS_GHC -fno-warn-orphans #-} -- | Optional instance of 'Text.Show.Show' for functions: -- -- > instance Show (a -> b) where -- > showsPrec _ _ = showString \"\<function\>\" -- ----------------------------------------------------------------------------- module Text.Show.Functions () where instance Show (a -> b) where showsPrec _ _ = showString "<function>" However, I consider this a questionable module to be in `base` due to its deliberate use of orphan instances. Should this module be deprecated, removed, alternatively, should the `Show` instance be made a non-orphan (e.g. by importing it by the `Prelude` module), or shall this curiousity be just left untouched in `base` in its current form? Cheers, hvr

11 18

FilePath modification proposal
by Neil Mitchell 20 Oct '14

20 Oct '14

Hi, As maintainer, it's kind of a grey area if I need to make proposals for the filepath library, but since I'm a relatively new active maintainer for a Core library, I thought I'd err on the side of caution. Please yell if you think these are a bad idea, otherwise I'll just do them (probably over the next few weeks). * Change 1: Add -<.> as an alias for replaceExtension with the same precedence as <.> This change has been in Shake for a while now, and seems generally useful. It isn't an operator in the lens library, and it reads nicely as a combination of - (remove something) and <.> (addExtension). The argument order of replaceExtension is a bit unfortunately, since replace functions usually have the thing to replace with first, but since extensions are at the end of the FilePaths that suggests making it the second argument (which is what filepath does). In contrast, -<.> has a very obvious argument order. * Change 2: Stop testing as part of GHC The test suite is complicated enough, since it generates code from the doc comments. Having the test suite also run by GHC complicates things further, since it has to integrate with the GHC test suite environment with extra Makefiles etc. Since August 2011 the FilePath test suite actually passes even if you break the properties (oops!) so it's provided no value at all in the last 3 years. In general, running all the tests in all the places is a good thing. But I think filepath is a bit different given it's exclusively cross-platform string manipulations, so I don't think its runtime behaviour is version/platform sensitive in any way. I also develop on Windows with 4 versions of GHC, and Travis tests it on Linux with 6 versions of GHC. That seems sufficient test coverage. * Change 3: Check in the generated test code If you check out the filepath repo it won't build - you have to run some code to generate the tests first. That's a barrier to entry, and makes testing with GHC harder. I'm increasingly starting to believe that for a small number of small files where the generator ships with the code, it's easier to check in the generated code and then have Travis run the generator and check nothing changes. It's easier to get started, easier to debug when things change, and the only real cost is a few extra checkins. Thanks, Neil

4 4