January 2018 - Libraries

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