September 2016 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Re: Numeric read seems too strict
by David Feuer 09 Oct '16

09 Oct '16

By the way, I believe we should be able to read numbers more efficiently by parsing them directly instead of lexing first. We have to deal with parentheses, white space, and signs uniformly for all number types. Then specialized foldl'-style code *should* be able to parse integral and fractional numbers faster than any lex-first scheme. On Sep 12, 2016 1:53 PM, "David Feuer" <david.feuer(a)gmail.com> wrote: I noticed the other day that readMaybe (fix ('a':)) :: Maybe Double is an infinite loop. The problem is that the lexer doesn't know that it's expected to lex a number. It just keeps scanning and scanning to get to the end of the endless token. Shall we fix this?

4 8

Generalise type of deleteBy
by Matthew Pickering 01 Oct '16

01 Oct '16

The type of `deleteBy` in `Data.List` could easily be generalised in a useful way. ``` deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] ``` to ``` deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] ``` There is this closed ticket but no reasons for not generalising. https://ghc.haskell.org/trac/ghc/ticket/3399 Discussion Period: 1 week. Matt

10 12

Proposal: add Monoid1 and Semigroup1 classes
by David Feuer 01 Oct '16

01 Oct '16

I've been playing around with the idea of writing Haskell 2010 type classes for finite sequences and non-empty sequences, somewhat similar to Michael Snoyman's Sequence class in mono-traversable. These are naturally based on Monoid1 and Semigroup1, which I think belong in base. class Semigroup1 f where (<<>>) :: f a -> f a -> f a class Semigroup1 f => Monoid1 f where mempty1 :: f a Then I can write class (Monoid1 t, Traversable t) => Sequence t where singleton :: a -> t a -- and other less-critical methods class (Semigroup1 t, Traversable1 t) => NESequence where singleton1 :: a -> t a -- etc. I can, of course, just write my own, but I don't think I'm the only one using such.

4 6

Bug in Eq/Ord typeclass documentation?
by Grant Wu 26 Sep '16

26 Sep '16

Neither Eq nor Ord have the types/summary of the methods that are part of the minimal complete definition listed. See http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq. Hopefully this is the right place to email. If not, apologies in advance. Thanks, Grant Wu grantwwu(a)gmail.com

2 1

Numeric read seems too strict
by David Feuer 12 Sep '16

12 Sep '16

I noticed the other day that readMaybe (fix ('a':)) :: Maybe Double is an infinite loop. The problem is that the lexer doesn't know that it's expected to lex a number. It just keeps scanning and scanning to get to the end of the endless token. Shall we fix this?

1 0

Discussion: name for reversing fromList in Data.Sequence
by David Feuer 05 Sep '16

05 Sep '16

I'd like to add a function fromListReversing :: [a] -> Seq a to Data.Sequence, with fromListReversing = reverse . fromList = fromList . reverse I don't know just what to call this function, however.

3 2

Modules for new map merge functions may be renamed
by David Feuer 02 Sep '16

02 Sep '16

We hope to make one more, fairly small, major release for containers for inclusion in GHC 8.2. I am considering renaming the new modules Data.Map.Merge.Lazy and Data.Map.Merge.Strict instead of Data.Map.Strict.Merge and Data.Map.Lazy.Merge. That seems more consistent with the module scheme for the rest of the package, and leaves open the option of adding extra merge-related modules in the future. I'm sorry about the potential wobble, but I think taking care of this now will lead to much less trouble than waiting till later.

1 0

Re: Discussion: name for reversing fromList in Data.Sequence
by David Feuer 01 Sep '16

01 Sep '16

My concern is for what happens when such rules don't fire. If someone converts a large list to a sequence only to reverse it, then the badly-ordered sequence will end up being evacuated by the garbage collector unnecessarily, pushing up the next major collection. In contrast, I've used rewrite rules to fuse map with reverse; the worst case there is some extra churn in the nursery. That said, if others don't consider it important enough, or have enough faith that rules will fire in this case (which may very well be), I can go the rules route. On Sep 1, 2016 3:51 PM, "John Wiegley" <johnw(a)newartisans.com> wrote: >>>>> "DF" == David Feuer <david.feuer(a)gmail.com> writes: FD> I'd like to add a function DF> fromListReversing :: [a] -> Seq a Hi David, Perhaps rather than proliferating the libraries with fused compositions that are faster than their composites via (.), we could defer things like this to REWRITE rules. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

1 1

Proposal: Add <&> to Data.Functor
by David Feuer 01 Sep '16

01 Sep '16

The <&> operator is rather popular: (<&>) :: Functor f => f a -> (a -> b) -> f b (<&>) = flip fmap Now that we have (&) in Data.Function, I think we should have (<&>) in Data.Functor.

8 7