October 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: 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

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

09 Oct '16

The second pass can be a huge problem for a failure. For example, when parsing a long string, we first look for an open parenthesis. To do so, we lex the next token. Supposing that's the string itself, we conclude that it is a string and not an open parenthesis, so we *throw it away and start over*. I hope to get the paren issue fixed for good at Hac Phi. Aside from that rather prominent one, I don't know how much the double scanning hurts, but it certainly can't *help* in most cases. In a more typical parsing situation, the parser would consume a stream of tokens instead of a list of characters. We can't do that here. On Oct 9, 2016 12:56 AM, "wren romano" <winterkoninkje(a)gmail.com> wrote: > > On Sat, Oct 1, 2016 at 8:34 PM, David Feuer <david.feuer(a)gmail.com> wrote: > > Instead of scanning first (in lexing) to find the end of the number and then > > scanning the string again to calculate the number, start to calculate once > > the first digit appears. > > Ah, yes. bytestring-lexing does that (among numerous other things). It > does save a second pass over the characters, but I'm not sure what > proportion of the total slowdown of typical parser combinators is > actually due to the second pass, as opposed to other problems with the > typical "how hard can it be" lexers/parsers people knock out. Given > the multitude of other problems (e.g., using Integer or other > expensive types throughout the computation, not forcing things often > enough to prevent thunks and stack depth, etc), I'm not sure it's > legit to call it a "parser vs lexer" issue. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

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