- Libraries - Haskell.org

Discussion: add pattern synonyms and a non-dependent eliminator to Numeric.Natural
by David Feuer 02 Nov '16

02 Nov '16

Pattern synonyms: pattern Successor :: Natural -> Natural pattern Successor n <- (precMaybe -> Just n) where Successor n = n + 1 precMaybe :: Natural -> Maybe Natural precMaybe 0 = Nothing precMaybe n = Just (n - 1) pattern Zero :: Natural pattern Zero = 0 Eliminator: toChurch :: Natural -> (a -> a) -> a -> a toChurch 0 _ b = b toChurch n f b = f (toChurch (n-1) f b) There are several other possible argument orders, the most natural of which is probably natural :: a -> (a -> a) -> Natural I don't have particularly strong feelings about whether we should pick one or offer both. There are two strictly accumulating versions, corresponding to different versions of foldl'. But toChurch/natural is sufficient to define them: toChurch', toChurch'' :: Natural -> (a -> a) -> a -> a toChurch' n f = toChurch n (\r acc -> r $! f acc) id toChurch'' n f = toChurch n (\r !acc -> r $ f acc) id So we shouldn't necessarily feel obligated to include those. I doubt the time is ripe for a dependent eliminator.

1 0

Proposal: Add Data instance for Const
by Ryan Scott 02 Nov '16

02 Nov '16

GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add deriving instance (Data a, Data b) => Data (Const a b) to Data.Data in base. Any objections? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438

4 6

Re: Type Level "Application" Operator
by Ryan Scott 02 Nov '16

02 Nov '16

> But this makes me wonder, is it actually *impossible* in Haskell to export from the same module a function with the same name at both the value and type level? Is it possible to export only one of the two? It's quite possible. You just have to use the "type" namespace in your export list to disambiguate the term-level and type-level ($)s: {-# LANGUAGE TypeOperators #-} module Money (($), type ($)) where type f $ x = f x infixr 0 $ Also, +1 on the original suggestion to add ($) to base. Ryan S.

1 0

Re: Few changes to deepseq
by Ryan Scott 27 Oct '16

27 Oct '16

All three of those proposals seem useful, broadly applicable, and sensibly named, so +1 from me. Ryan S.

1 0

Typelevel Symbol concatenation
by Oleg Grenrus 25 Oct '16

25 Oct '16

There is an issue #1216: "concatenation of type level symbols missing" [1]. I made a working patch, but we need to figure out the details. As the patch introduces new non-obvious name to the base library, I’m starting a thread in libraries@ to figure out community's opinion. I’m proposing to add `type family (n :: Symbol) <> (m :: Symbol)` to `GHC.TypeLits`. Currently implementation uses (<>). Another options are (++), (+++) or `AppendSymbol`. - (<>) resembles Semigroup operation, as (+) resembles Num operation - (++) is a list appending operation. IMHO it’s a bad choice - (+++) is used by ghc-typelits-symbols plugin - `AppendSymbol` is sensible too, if libraries want to define own versions of type-level (<>) (e.g. polykinded) Discussion period: 2 weeks. Cheers, Oleg Grenrus. - [1] https://ghc.haskell.org/trac/ghc/ticket/12162 <https://ghc.haskell.org/trac/ghc/ticket/12162> - [2] https://github.com/konn/ghc-typelits-symbols/blob/cd812f4cfc2e6816a18283a6a… <https://github.com/konn/ghc-typelits-symbols/blob/cd812f4cfc2e6816a18283a6a…>

2 1

Few changes to deepseq
by Oleg Grenrus 25 Oct '16

25 Oct '16

About two weeks ago i made three small PR to `deepseq` [1,2,3], to resolve three long standing issues [4,5,6] As deepseq is a core package, I bring these issues and pull requests to the libraries@ attention, so the pull requests could be merged or declined, and issues resolved in way or another. - The `rwhnf` [1] helper is straightforward, I hope that it will be accepted as is. - The deeply strict liftM, aka <$!!> [2], is discussed a bit in the issue [5]. I think this is quite straightforward as well. Side note: It's not obvious what this operator does, also neither $!, <$!> or $!! documentation explains them properly. IMHO Improving the documentation of these operators should be done as a separate chore, there is something on wiki [7], but that description is quite sparse as well, but I'm not competent enough to do that. Is there some good resource? - The NFData1 and NFData2 classes. The PR [3] proposes: class NFData1 f where liftRnf :: (a -> ()) -> f a -> () definition. The is also some discussion about `rnf1 :: NFData a => f a -> ()` would be enough. I'm not repeating it here, `liftRnf` is just more powerful. I'll add Generics support, if the addition is approved. For the record, I think that polykinded `NFData` is not a good idea, yet. As this is 3-proposals-in-1, the discussion time is 3 weeks, ending Nov 14. Cheers, Oleg Grenrus, aka phadej - [1]: rwhnf: https://github.com/haskell/deepseq/pull/22 - [2]: deeply strict liftM: https://github.com/haskell/deepseq/pull/23 - [3]: NFData1/2: https://github.com/haskell/deepseq/pull/21 - [4]: rwhnf: https://github.com/haskell/deepseq/issues/3 - [5]: deeply strict liftM: https://github.com/haskell/deepseq/issues/13 - [6]: NFData1 helper https://github.com/haskell/deepseq/issues/8 - [7]: https://wiki.haskell.org/Performance/Strictness#Evaluating_expressions_stri…

1 0

Generic Data.List.partition
by evan＠evan-borden.com 20 Oct '16

20 Oct '16

I've been curious in the past why Data.List.partition has not found a more generic implementation. I always assumed this was because of performance. I've given the performance hypothesis a test and it seems that a generic implementation outperforms the list implementation. I'm not terribly sure why this is the case, but I also haven't dumped core. Implementation and bench: https://github.com/eborden/partition Should this function be made generic? This implementation is surely leveraging the perf characteristics of the Monoid instance of List. Other types could have terrible performance. - Evan

3 3

Adding Fixed Point Data Types to base
by Andrew Martin 20 Oct '16

20 Oct '16

I would like to propose export Fix, Free, and Cofree from a new module in base (maybe something like Data.Functor.Recursion, the name is unimportant). The definitions of Free and Cofree would be as there are in the `free` package in Control.Monad.Free and Control.Monad.Cofree. The `free` package would then reexport these types in their respective modules rather than redefining them. All of the other utilities functions from these packages would not be moved to `base`; they would remain in `free`. Fix would be defined as: newtype Fix f = Fix { unFix :: f (Fix f) } The advantage this offers is that Free and Cofree would be able to enjoy a greater number of typeclass instances provided libraries across the ecosystem. As it stands, adding the somewhat heavy `free` dependency is not a good choice for libraries like `aeson`, `mustache`, and `hashable`. In the case of Fix, the ecosystem currently lacks a canonical library that provides it (recursion-schemes and data-fix both offer the same definition though, and various tutorials all define it the same way). It could benefit from the new instances as well. The disadvantage is the usual disadvantage: Adding any data type to base is a future commitment to that data type, and compile times for base go up a little, and there is work to be done to move it into base to begin with. I would gladly help with any of the work that needs to be done to make this happen. I believe that Fix and Free (and Cofree to a lesser extent) have proved themselves over years of use in the ecosystem. I would appreciate any feedback or thoughts that others have on this topic. Thanks. -- -Andrew Thaddeus Martin

8 15

Primitive package on hackage out of date?
by Twan van Laarhoven 16 Oct '16

16 Oct '16

Hi libraries list, It seems that the `primitive` package on Hackage is out of date. The version on github has more functions such as `sizeofArray`, as well as support for SmallArrays. Could the new version be uploaded to Hackage? Or is there a reason why it can't be? The version number is the same for both though (0.6.1.0), so the cabal file should probably be updated first. Twan

3 3

Read for integral types: proposed semantic change
by David Feuer 09 Oct '16

09 Oct '16

I have undertaken[*] to improve the Read instances for a number of types in base. My primary goal is to make things run faster, and my secondary goal is to make things fail faster. The essence of my approach is to abandon the two-stage lex/parse approach in favor of a single-phase parse-only one. The most natural way to do this makes some parsers more lenient. With GHC's current implementation, given readsInt :: String -> [(Int, String)] readsInt = reads we get readsInt "12e" = [(12, "e")] readsInt "12e-" = [(12,"e-")] readsInt "12e-3" = [] readsInt ('a' : undefined) = undefined This is because the Read instance for Int calls a general lexer to produce tokens it then interprets. For "12e-3", it reads a fractional token and rejects this as an Int. For 'a': undefined, it attempts to find the undefined end of the token before coming to the obvious conclusion that it's not a number. For reasons I explain in the ticket, this classical two-phase model is inappropriate for Read--we get all its disadvantages and none of its advantages. The natural improvement makes reading Int around seven times as fast, but it changes the semantics a bit: readsInt "12e" = [(12, "e")] --same readsInt "12e-" = [(12,"e-")] --same readsInt "12e-3" = [12,"e-3"] --more lenient readsInt ('a' : undefined) = [] --lazier As I understand it, GHC's current semantics are different from those of the Haskell 98 reference implementation, and mine come closer to the standard. That said, this would be a breaking change, so the CLC's input would be very helpful. The alternative would be to bend over backwards to approximate the current semantics by looking past the end of an Int to see if it could look fractional. I don't much care for the non-monotone nature of the current semantics, so I don't think we should go to such lengths to preserve them. [*] https://ghc.haskell.org/trac/ghc/ticket/12665

3 3