- Libraries - Haskell.org

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

Proposal: Improve error messages for (!!) (include index and length of list)
by Simon Hengel 17 Oct '14

17 Oct '14

Hi, currently we have the following implementation for (!!): #ifdef USE_REPORT_PRELUDE xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) #else -- HBC version (stolen), then unboxified xs !! (I# n0) | isTrue# (n0 <# 0#) = error "Prelude.(!!): negative index\n" | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = error "Prelude.(!!): index too large\n" sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) #endif I propose to change the error messages for the non-report version to include index and list length, something that is functionally equivalent to: xs !! (I# n0) | isTrue# (n0 <# 0#) = indexError xs n0 | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = indexError xs n0 sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) indexError :: [a] -> Int# -> b indexError xs (I# -> n) | n < 0 = error ("Prelude.(!!): negative index " ++ show n) | otherwise = error ("Prelude.(!!): index " ++ show n ++ " too large for list of length " ++ show (length xs)) Some usage examples: *Main> [1, 2, 3] !! (-1) *** Exception: Prelude.(!!): negative index -1 *Main> [1, 2, 3] !! 3 *** Exception: Prelude.(!!): index 3 too large for list of length 3 This will require some refactoring, i.e. we need to move itos from GHC.Show to e.g. GHC.Base. Discussion period: 2 weeks Cheers, Simon

5 5

Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf
by David Feuer 15 Oct '14

15 Oct '14

Currently, isSuffixOf is defined like this: xs `isSuffixOf` ys = reverse xs `isPrefixOf` reverse ys If ys is much longer than xs, this is not so wonderful, because we have to reverse the whole spine of ys. It also will fail whenever either xs *or* ys is infinite. The following implementation seems a lot saner (although longer): isSuffixOf :: forall a . (Eq a) => [a] -> [a] -> Bool [] `isSuffixOf` _ = True needle `isSuffixOf` hay = maybe False (\fp -> needle `eq` getEndChunk hay fp) (getFrontPointer needle hay) where eq :: [a] -> [a] -> [a] (x:xs) `eq` (y:ys) = x==y && (xs `eq` ys) getEndChunk :: [a] -> [a] -> [a] getEndChunk (_:hy) (_:fp) = getEndChunk hy fp getEndChunk hy _ = hy getFrontPointer :: [a] -> [a] -> Maybe [a] getFrontPointer [] hy = Just hy getFrontPointer _ [] = Nothing getFrontPointer (_:nd) (_:hy) = getFrontPointer nd hy This doesn't do any of that crazy stuff, and it will work just fine if the needle is infinite. The only slightly sticky point is that it's not *strictly* lazier. In particular, [1,2] `Data.List.isSuffixOf` [undefined, 7] = False [1,2] `isSuffixOf` [undefined, 7] = undefined But note that [1,2] `Data.List.isSuffixOf` [7,undefined] = undefined [1,2] `isSuffixOf` [7, undefined] = False It would be possible to get the same kind of laziness at the end using something structured as above, but it requires some unpleasantness: instead of using needle `eq` getEndChunk hay fp we'd have to use needle `backwardsEq` getEndChunk hay fp (x:xs) `backwardsEq` (y:ys) = (xs `backwardsEq` ys) && x==y This is yucky. My guess is that no one is relying on the current behavior, but I'd like to make sure everyone's okay with this. David

7 23

Re: Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf
by David Feuer 14 Oct '14

14 Oct '14

On Oct 14, 2014 9:05 AM, "Kim-Ee Yeoh" <ky3(a)atamo.com> wrote: > > David, > > To paraphrase Kernighan, ascertaining correctness is twice as hard as writing a program in the first place. So if you're as clever as possible with your code, how will you know it's even correct? I think we have different senses of what is easy to understand. We're all working on modifications of Andreas Abel's "naive" approach. I don't think the Reid Barton/Kim-Ee Yeoh modification is easier to understand than the David Feuer/Milan Straka one. In particular, your approach makes the weird long needle/short haystack case implicit, dumping it into the equality test. I also think the principle of least (bad) surprise applies: I wouldn't *expect* an overly long needle to be traversed in full and then the elements compared. > Case in point: the infinite lists wrinkle that you started the thread with. /At a glance/ what do the general recursion versions (yours and Milan's) evaluate to on infinite lists? I can't undo my understanding and say what I would have thought. But it's certainly a whole lot easier to understand than, say, the `permutations` or `sort` functions, and I could easily add two or three lines of explanation that would guide anyone to a correct interpretation. > What are the benchmarks on the time it takes for a haskell programmer to figure them out? Would they not jump at the greater affordance of reasoning with Andreas's compositions? Let me know when the benchmarks and experimental results are in. Don't forget to get IRB approval for human trials. > Meaning and reasonableness have always been the hallmarks of core libs. I think we have an honest disagreement hear about what is "reasonable". I think it's unreasonable for [undefined, undefined] `isSuffixOf` [undefined] to be undefined, but you see it differently. > Least of all, since it's so losering to benchmark the wrong thing, see below on how Andreas-dropl no.1 beats out David-Milan by the tiniest sliver in short-needle-long-haystack. Like checking file extensions in pathnames that we saw in Andreas's Agda code. The "long haystack" benchmark I used is actually much, much longer than a path name. My "short needle, short haystack" example is the one designed to test the pathname extension performance. > Here a concrete app brings real meaning to the timings as opposed to optimizing for vaporware. Watch them Agdaists fall off their chairs when they hit the speed boost. ;)

1 0