- Libraries - Haskell.org

generalized IntMap - IntegerMap or IntegralMap
by Henning Thielemann 22 Jan '18

22 Jan '18

I want to use Word32 or Word64 bit patterns as indices for a Map. I have checked that IntMap is more efficient than Map in my application. However, the Haskell 98 report warrants only 30 bits for Int including the sign bit. Is there a generalization of IntMap for Map Integer or (Integral k, Bits k) => Map k or would there be general interest in such a data structure?

4 8

ANNOUNCE: servant-pandoc 0.5.0.0
by Ivan Lazar Miljenovic 16 Jan '18

16 Jan '18

I'm pleased to announce the latest release of the servant-pandoc library: https://hackage.haskell.org/package/servant-pandoc-0.5.0.0 servant-pandoc allows you to take the documentation created with servant-docs and use Pandoc to convert it into whichever format you want (rather than the Markdown generated by servant-docs). The main changes in this release are to provide compatibility with servant-docs-0.11.1; specifically, servant-pandoc now emits all the information that servant-docs does with the same configuration options. As such, there are behavioural changes which necessitated the major version bump. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Taking over maintainership of cabal2spec
by Peter Simons 16 Jan '18

16 Jan '18

Fellow Haskell Hackers, I would like to take over the package cabal2spec [1], which hasn't seen any activity in the last 9 years. I have tried to contact the Hackage maintainers Conrad Meyer and Yaakov M. Nemoy to get them involved in the decision, but unfortunately I was unable to reach either one of them. Best regards, Peter [1] http://hackage.haskell.org/package/cabal2spec

2 2

Re: Proposal: Lifting to TExpQ
by Dan Burton 15 Jan '18

15 Jan '18

+1 to Michael's suggestion; that's basically the same thing I would have suggested, modulo bikeshedding. On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan(a)gmail.com> wrote: Hmm, I'm not sure about changing the Lift class, there are good reasons to leave it the same and good reasons to change as well. There is a lot of precedent for providing safe functions which use unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text). Also, not much of the TH API uses TExp, just typed splices. On the other hand, it does make the method's type stronger and directly suggest more properties. It may encourage people to use typed splices to define manual instances, which I think is good. I propose a somewhat less breaking change, defining the following: class Lift t where typedLift :: t -> Q (TExp t) lift :: Lift t => t -> Q t lift = fmap unType . typedLift The advantage of this is that a lot more code depends on usage of 'lift' than defining instances of 'Lift'. A lot of the code that defines instances of 'Lift' does it via the 'th-lift' package. I believe that only a handful of packages would need to be updated as a result of this change, vs the dozens that would need to be updated by changing the type of 'lift'. Even after this change, I think that since 'TExp' is only useful with typed splices, the 'lift' form would still find much more usage as the more convenient function. -Michael _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

3 2

Proposal: Lifting to TExpQ
by Emil Axelsson 13 Jan '18

13 Jan '18

Hi! I wasn't able to find a function like this anywhere: liftT :: Lift a => a -> TExpQ a liftT = unsafeTExpCoerce . lift It seems like a nice addition that would reduce the need for `unsafeTExpCoerce` in user code. Should it be added? / Emil

3 3

Proposal: add unzips for Data.Sequence
by David Feuer 12 Jan '18

12 Jan '18

Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to Data.Sequence. I agree. I propose adding unzip :: Seq (a,b) -> (Seq a, Seq b) unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b) Does anyone object?

5 6

Constraint implication
by Ryan Reich 02 Jan '18

02 Jan '18

The Constraint kind appears to lack an interface to an important capability that is already part of the type checker: constraint implication. Namely, the ability to provide a witness for the statement "constraint c1 implies constraint c2" or, more importantly, "for all a, constraint (c1 a) implies constraint (c2 a)", where c1 and c2 are now constraint-valued type functions (and possibly even for constraint functions with multiple parameters). It seems to me that this can follow the pattern of the "magic" Coercible type class and the (non-magic) Coercion data type; it provides the programmer with an analogous value to this example that can be obtained in apparently no other way.

5 6

add a new equation to Data.Type.Bool.If
by Richard Eisenberg 29 Dec '17

29 Dec '17

Currently, we have (in Data.Type.Bool): > -- | Type-level "If". @If True a b@ ==> @a@; @If False a b@ ==> @b@ > type family If cond tru fls where > If 'True tru fls = tru > If 'False tru fls = fls I propose adding a new equation, thus: > -- | Type-level "If". @If True a b@ ==> @a@; @If False a b@ ==> @b@ > type family If cond tru fls where > If b same same = same > If 'True tru fls = tru > If 'False tru fls = fls This new equation would allow If to reduce when we don't know the condition but we do know that both branches are the same. All three equations are *compatible* (a technical term defined in the closed type families paper), meaning that GHC ignores the ordering between them and will just choose whichever equation matches. Any objections? Thanks, Richard

3 5

Proposal: simplify type of ($)
by David Feuer 28 Dec '17

28 Dec '17

Currently, we have something like ($) :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b f $ x = f x And that's only part of the story: GHC has a hack in the type checker to give ($) an impredicative type when fully applied. This allows it to be used when its function argument requires a polymorphic argument. This whole complicated situation could be resolved in a very simple manner: change the type and definition thus. ($) :: a -> a ($) f = f All the type complications go away altogether, and ($) becomes plain Haskell 98. There are only three potential downsides I can think of: 1. The optimizer will see `($) x` as fully applied, which could change its behavior in some cases. There might be circumstances where that is bad. I doubt there will be many. 2. The new type signature may obscure the purpose of the operator to beginners. But based on my experience on StackOverflow, it seems beginners tend to struggle with the idea of ($) anyway; this may not make it much worse. I suspect good Haddocks will help alleviate this concern. 3. Some type family and class instances may not be resolved under certain circumstances which I suspect occur very rarely in practice. class C a where m :: (a -> a) -> () instance C (a -> b) where m _ = () test :: () test = m ($) Today, this compiles with no difficulties; with the proposed change, the user would have to supply a type signature to make it work: test = m (($) :: (a -> b) -> (a -> b)) This can also change when an INCOHERENT instance is selected under similarly contrived circumstances, but those who use such generally deserve what they get. David

5 7

PROPOSAL: Add `disjoint` method to `Data.IntSet`
by Víctor López Juan 28 Dec '17

28 Dec '17

Proposal: Add a method disjoint :: IntSet → IntSet → Bool, to Data.IntSet, such that prop> disjoint a b ≡ null (intersection a b) Alternatively or additionally, add a method overlaps :: IntSet -> IntSet -> Bool such that prop> a `overlaps` b ≡ not.null$ intersection a b Rationale: - I have found it useful to have such a method when keeping track of the set of free-variables in a term. I believe that there can be more use cases. - There are already similar specialized implementations in the library. For example, isSubsetOf :: IntSet -> IntSet -> Bool is such that prop> a `isSubsetOf` b ≡ (a == (a `intersection` b)). - Having `disjoint`, the user can also check whether two sets overlap with `(not.).disjoint`. This is shorter and more self-explaining than (not.null$ intersection). - A specialized implementation of `disjoint` (vs. (null.).intersection) can shortcircuit as soon as the sets overlap on one element. This leads to significant speed-ups; for example, 23× when checking that the sets {1,2,3…,2¹²} and {2,4,6,…,2¹²} are not disjoint [1]. Discussion: I would like to get some comments on this proposal. In particular: - Should any of these methods be added? - Should both `overlaps` and `disjoint` be added? - If only one of them is added, which one should it be? I hope a decision about the proposal can be reached before 2018-01-09. See also: - Proposed patch [2] - Previous discussion [3] [1] https://github.com/haskell/containers/pull/377#issuecomment-352585171 [2] https://github.com/haskell/containers/pull/377/files [3] https://github.com/haskell/containers/pull/377

8 8