- Libraries - Haskell.org

Re: Discussion: reconsider lens-like exports from containers
by David Feuer 26 Apr '16

26 Apr '16

I *believe* that the [] Applicative will prove that adjustA is sometimes more efficient than any implementation built on the current API. In that context, it should be possible to descend to a leaf once and then ascend from it many times. foo n xs = adjustA f n xs where f :: Char -> [Char] f x = ... This only travels to the nth element once and effectively saves the path to that spot so it can produce many sequences where that element is different. You could do something conceptually similar by splitting the sequence at that point and putting the pieces together many times, but in practice that would be awful. On Apr 26, 2016 3:18 PM, "Marcin Mrotek" <marcin.jan.mrotek(a)gmail.com> wrote: Hello, I don't feel qualified to take a stance on this, but since you did make a comment about "deafening silence" earlier on an unrelated issue, then, if this `adjustA` doesn't depend on any particular Lens library, and it's more efficient than any hand-rolled solution, then why not? Best regards, Marcin Mrotek

1 0

Proposal: Add rtsIsThreaded to base
by Merijn Verstraaten 26 Apr '16

26 Apr '16

I would propose adding a Bool value to base that indicates whether the code was compiled/linked with the threaded or single threaded runtime system. A library might want to implement certain functionality differently depending on whether the threaded runtime system is used (i.e. avoid blocking C FFI calls in single-threaded). There is currently no good way to do this. StackExchange currently suggests using "Control.Concurrent.rtsSupportsBoundThreads" for this, which is defined as: HsBool rtsSupportsBoundThreads(void) { #if defined(THREADED_RTS) return HS_BOOL_TRUE; #else return HS_BOOL_FALSE; #endif } But it seems undesirable to conflate support for bound threads and use of the threaded runtime system? Especially since this would be a trivial addition to Control.Concurrent (i.e. simply an ifdef'ed True/False constant). Cheers, Merijn

2 2

Proposal: Export cycleN from Data.Sequence
by David Feuer 26 Apr '16

26 Apr '16

Yesterday I rewrote `*>` for Data.Sequence (again), using an internal function cycleN :: Int -> Seq a -> Seq a The name of the function is based on that of Data.Sequence.iterateN. cycleN takes a sequence and cycles it as many times as requested: cycleN 0 $ fromList [1,2] = [] cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] The function is written to maximize sharing in the result sequence and to minimize construction time. Specifically, cycleN n xs should take something like O(|xs| + log n) space (of which all but O(log |xs| + log n) is shared with the structure of xs) and O(log |xs| + log n) time. With current (on GitHub) Data.Sequence exports, the only way to get this functionality with these time and space bounds is to combine replicate with *> : cycleN n xs = replicate n () *> xs This strikes me as a bit unpleasant. David

3 3

Dropping support for NHC98 and old GHC from containers
by David Feuer 25 Apr '16

25 Apr '16

The containers package currently includes CPP and Cabal directives intended to support NHC98 and versions of GHC before 7.0. However, our TravisCI script tests only GHC versions 7.0 and above. It is therefore likely that the compatibility code is bit-rotted to some extent. Wren Romano and I are strongly inclined to immediately remove all code intended to support NHC98 or pre-7.0 GHC. If anyone uses any such implementations with the current version of containers, please speak now or forever hold your peace. Thanks, David Feuer

3 2

Types for Data.Sequence pattern synonyms
by David Feuer 25 Apr '16

25 Apr '16

As discussed, I plan to add pattern synonyms Empty, :<|, and :|> to make working with sequences more convenient. The remaining question is what types they should have. From the Data.Sequence standpoint, the best thing would be to make them work *only* for Seq, so that the Seq type will be inferred from their use. However, modules using multiple sequence types might benefit from more flexibility, via ad hoc classes. This, however, requires that something else pin down the sequence type, and could cause more confusing error messages. I'm leaning toward the simple, monomorphic approach, but I figured I should ask here in case anyone disagrees strongly. {-# LANGUAGE PatternSynonyms, ScopedTypeVariables, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, ViewPatterns #-} module Patt where import Data.Sequence as S import Prelude as P class FastFront x xs | xs -> x where fcons :: x -> xs -> xs fviewl :: xs -> ViewLS x xs class FastRear x xs | xs -> x where fsnoc :: xs -> x -> xs fviewr :: xs -> ViewRS x xs class FastEmpty x xs | xs -> x where fMkEmpty :: xs fIsEmpty :: xs -> Bool instance FastFront a (Seq a) where fcons = (<|) fviewl xs = case viewl xs of EmptyL -> EmptyLS y :< ys -> ConsLS y ys instance FastFront a [a] where fcons = (:) fviewl [] = EmptyLS fviewl (x : xs) = ConsLS x xs instance FastRear a (Seq a) where fsnoc = (|>) fviewr xs = case viewr xs of EmptyR -> EmptyRS ys :> y -> SnocRS ys y instance FastEmpty a (Seq a) where fMkEmpty = mempty fIsEmpty = S.null instance FastEmpty a [a] where fMkEmpty = [] fIsEmpty = P.null data ViewLS x xs = EmptyLS | ConsLS x xs data ViewRS x xs = EmptyRS | SnocRS xs x pattern x :<| xs <- (fviewl -> ConsLS x xs) where x :<| xs = fcons x xs pattern xs :|> x <- (fviewr -> SnocRS xs x) where xs :|> x = fsnoc xs x pattern Empty <- (fIsEmpty -> True) where Empty = fMkEmpty

4 3

prelude-compat, prelude2010
by Henning Thielemann 16 Apr '16

16 Apr '16

Here is my attempt to make packages compile with GHC-7.10 and older compilers without warnings: https://hackage.haskell.org/package/prelude-compat-0.0/candidate https://hackage.haskell.org/package/prelude2010-0.0/candidate The idea is that prelude2010:Prelude maintains the export list of haskell2010:Prelude such that you are saved both from identifier conflicts and warnings about redundant imports of Data.Foldable etc. Unfortunately, when I try to use it on GHC-7.8.4 together with base-noprelude, I am told that base-noprelude cannot be installed with Cabal-1.22. :-( However, when thinking about adapting all my packages to this work-around I'd prefer to switch to the real solution, namely split base packages that can be upgraded independently from GHC.

1 1

Re: GHC 8 and Template Haskell
by Ryan Scott 15 Apr '16

15 Apr '16

> I've done a quick grep for InstanceD over the stackage-nightly-subset of Hackage: Wouldn't we also need to check for the instanceD function from Language.Haskell.TH.Lib as well? I know several of my packages use that exclusively over the InstanceD constructor, and I imagine others do as well. Ryan S.

2 2

GHC 8 and Template Haskell
by Iavor Diatchki 15 Apr '16

15 Apr '16

Hello, Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate. If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP. Let me know, -Iavor

6 9

New maintainers of containers
by Milan Straka 13 Apr '16

13 Apr '16

Hi David and Edward, following the announcement and small discussion at libraries@haskell, I have added you both as maintainers of containers on github and on hackage. The idea is that David will take care of Data.Sequence, and CLC will manage the rest (at least until someone else appears, like wren). I have added only you Edward on behalf of CLC, but you can add others if you like (you should have the rights to do it). I would like to note that since containers are widely used and needed by GHC itself, I consider the CLC to have the final word if any disagreement ever arises between CLC and other container maintainers (David, wren, ...). Also please consider backward compatibility very highly. I will stop reading libraries@haskell and also containers github notifications soon, but feel free to write me an email or mention me on github (using @foxik) if you need to contact me. Cheers, Milan Straka

2 1

Proposal: Add functions to get consecutive elements to Data.List
by Johan Holmquist 13 Apr '16

13 Apr '16

I propose adding two new functions to Data.List: zipConsecutives :: [a] -> [(a,a)] zipConsecutives xs = zip xs (tail xs) zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b] zipConsecutivesWith f xs = zipWith f xs (tail xs) (with possibly more efficient implementations) The Trac feature request is at https://ghc.haskell.org/trac/ghc/ticket/11815 . Why These functions are useful when one wants to process consecutive pairs of elements in a sequence, which is not uncommon. The ticket lists some examples, reiterated here: -- diff consecutive elements: diffs = zipConsecutivesWith (flip (-)) -- determine if list is ascending (similar for descending and strict): isAscending = and . zipConsecutivesWith (<=) -- an old friend of ours: fibs = 1 : 1 : zipConsecutivesWith (+) fibs -- get the edges of a closed path defined by points (ps): edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps) Why add to Data.List (and base) The definition must either use an extra equation for the empty list case: zipConsecutives [] = [] zipConsecutives xs = zip xs (tail xs) which makes it non practical to define inline at each use site. Or one may omit the empty list equation, which is safe (thanks to laziness), but that may not be immediately obvious. (It wasn't to me anyway.) The tail function is generally considered unsafe so it is not desirable to force the user to use it. The proposed functions would offer an alternative. The Data.List module is often imported unqualified, so new identifiers may cause collissions. I do find it rather unlikely that the proposed names would cause such problems, however. Deadline for discussion: 2016-05-31.

9 16