- Libraries - Haskell.org

Haddock with GHC 8
by Dominic Steinitz 14 Dec '15

14 Dec '15

Hello All, I submitted a PR for Haddock to support mathjax on 16 May. As I understand it, the maintainer of Haddock did not wish to apply it immediately as it would change interface files (although I have to admit I don’t know what this entails). Are there any plans to release a new version of Haddock along with GHC 8? Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

3 4

cabal-install 1.24
by Jeremy 10 Dec '15

10 Dec '15

What's the status of cabal-install 1.24? https://github.com/haskell/cabal/milestones shows it as 3 months overdue and 12% complete. My concern is over https://github.com/haskell/cabal/pull/2826, which is a show-stopper for some of my work, but doesn't seem to be in any released branch. -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-1-24-tp5824017.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 1

3 release policy and -Wno-compat
by Jeremy 30 Nov '15

30 Nov '15

The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings. I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit. (I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

3 9

Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Herbert Valerio Riedel 27 Nov '15

27 Nov '15

Hello *, Concluding AMP and MFP, We (David and I) proudly present you the final installment of the Monad trilogy: Monad of no `return` Proposal ============================= TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Current Situation ----------------- With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy becomes class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b u *> v = … (<*) :: f a -> f b -> f a u <* v = … class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a return = pure (>>) :: m a -> m b -> m b m >> k = … class Monad m => MonadFail m where fail :: String -> m a Consequently, the `Monad` class is left with a now redundant `return` method as a historic artifact, as there's no compelling reason to have `pure` and `return` implemented differently. Traditionally, `return` is often used where `pure` would suffice today, forcing a `Monad` constraint even if a weaker `Applicative` would have sufficed. As a result, language extensions like `ApplicativeDo`[3] have to rewrite `return` to weaken its `Monad m =>` constraint to `Applicative m =>` in order to benefit existing code at the cost of introducing magic behavior at the type level. Finally, this redundancy becomes even more significant when viewed in light of the renewed Haskell standardisation process[7]: The next Haskell Report will almost certainly incorporate the AMP (and MFP) changes, and there's no justification for the Report to retain `return` as a method of `Monad`. A good reason would have been to retain backward compatibility with Haskell 2010. However, as the AMP superclass hierarchy requires `Monad` instances to be accompanied by `Applicative` instances (which aren't part of Haskell 2010, c.f. [6]), backward compatibility with Haskell 2010 goes out the window when it comes to defining `Monad` instances (unless via use of `-XCPP` or similar). Consequently, meeting the high bar for a formal document such as the Haskell Report demands that `Monad` shall not carry a redundant `return` method that serves no purpose anymore. Moreover, getting `return` out of the way is desirable to facilitate standardising potential candidates such as the earlier mentioned `ApplicativeDo` in the future and avoids the technical debt incurred by keeping around this language wart. Proposed Change --------------- Remove `return` as a method from the `Monad` class and in its place define a top-level binding with the weaker `Applicative` typeclass constraint: -- | Legacy alias for 'pure' return :: Applicative f => a -> f a return = pure This allows existing code using `return` to benefit from a weaker typeclass constraint as well as cleaning the `Monad` class from a redundant method in the post-AMP world. A possible migration strategy is described further below. Compatibility Considerations ---------------------------- Generalizing the type signature of a function from a `Monad` constraint to its superclass `Applicative` doesn't cause new type-errors in existing code. However, moving a method to a top-level binding obviously breaks code that assumes `return` to be a class method. Foremost, code that defines `Monad` instances it at risk: ### Instance Definitions Code defining `return` as part of an instance definition breaks. However, we had the foresight to provide a default implementation in `base-4.8` for `return` so that the following represents a proper minimal instance definition post-AMP: instance Functor Foo where fmap g foo = … instance Applicative Foo where pure x = … a1 <*> a2 = … instance Monad Foo where m >>= f = … -- NB: No mention of `return` Consequently, it is possible to write forward-compatible instances that are valid under this proposal starting with GHC 7.10/`base-4.8`. Heuristically `grep`ing through Hackage source-code reveals a non-negligible number of packages defining `Monad` instances with explicit `return` definitions[4]. This has a comparable impact to the AMP, and similarly will require a transition scheme aided by compiler warnings. ### Module Import/Export Specifications A second source of incompatibility may be due to `import`s. Specifically module import that assert `return` to be a method of `Monad`, e.g.: import Control.Monad (Monad ((>>=), return)) or import Prelude hiding (Monad(..)) import Control.Monad (Monad(..)) as Monad f = Monad.return () The dual situation can occur when re-exporting `return` via module export specifications. However, given that `return` is exported by `Prelude` and the examples above are rather artificial, we don't expect this to be a major source of breakage in the case of `return`. In fact, a heuristic grep[5] over Hackage source-code revealed only 21 packages affected. ### Example for writing compatible code instance Functor Foo where fmap g foo = … instance Applicative Foo where pure x = … a1 <*> a2 = … instance Monad Foo where m >>= f = … #if !(MIN_VERSION_base(4,8,0)) return = pure #endif Migration Strategy ------------------ The migration strategy is straightforward: **Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets triggered when `Monad` instances explicitly override the default `return` method implementation. **Phase 2** *(GHC 8.2 or later)*: When we're confident that the majority of Hackage has reacted to the warning (with the help of Stackage actively pursuing maintainers to update their packages) we turn the `return` method into a top-level binding and remove the warning implemented in Phase 1 from GHC again. Discussion period ----------------- A discussion period of three weeks (until 2015-10-15) should be enough to allow everyone to chime in as well as leave enough time to make the required preparations for GHC 8.0 should this proposal pass as we hope. ---- [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [2]: https://wiki.haskell.org/MonadFail_Proposal [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9 [5]: https://gist.github.com/hvr/afcd040783d980594883 [6]: https://ghc.haskell.org/trac/ghc/ticket/9590 [7]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html --

41 98

regex-posix broken on 64 bit windows.
by Gershom B 26 Nov '15

26 Nov '15

Here’s a ticket reporting the issue: https://github.com/haskell/haskell-platform/issues/144 The ticket is on the platform site, but it doesn’t really belong there. On the other hand, there’s no tracker for regex-posix anywhere else. This problem has probably existed for a _long_ time, and I guess has to do with 64-bit incompatibilities in the cbits shipped with the package. I’ve cc’d Chris Kuklewicz as he is author and maintainer. But I know that he has taken a step back from these packages some time ago. Generally, I would be happy to consider them stable-ish and let the community just migrate away from them or not as open source typically evolves. But regex-posix is pretty widely used still and is in the platform, so I think it is unfortunate that it is broken in this way. It would be great if some interested volunteer were to step up and fix this issue and maybe even offer to take over maintainership (to which I’m sure Chris would have no objection?). (Relatedly, it would be good to have a future discussion on which regex library, if any, is suitable for inclusion in the platform. At this point my inclination would be regex-tdfa-text, although my sense is nearly all the libs are relatively unmaintained at this point?) —Gershom

1 0

On parsing Haskell and CPP
by Gershom B 22 Nov '15

22 Nov '15

We've had quite a bit of discussion lately on the difficulty in performing automated processing of Haskell files in the presence of CPP. It turns out that folks have tackled this sort of problem in the world of C, and done some interesting work. I recently ran across SuperC [1], part of the xtc [2] project. In the setting of C they have achieved some impressive results, including as I understand it, the ability to handle the entire Linux kernel across all CPP-recognized configurations. They note that this is a rather tedious to implement task, even once one has recognized the specification of how to do so. However, the paper is good at reviewing related work and simpler techniques as well, and perhaps among them there is a "good enough" set for the CPP used in common Haskell libraries? Cheers, Gershom [1] https://cs.nyu.edu/rgrimm/papers/pldi12.pdf [2] http://cs.nyu.edu/xtc/

1 0

Re: [Coq-Club] ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 20 Nov '15

20 Nov '15

>>>>> Beta Ziliani <bziliani(a)famaf.unc.edu.ar> writes: > I'd be interested to know what was the outcome of the project from the point > of view of BEA Systems. Is there any report about it? >From BAE's point of view, we gained some industrial perspective. Separately, I have prepared an experience report that is currently seeking a venue. John

1 0

ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 20 Nov '15

20 Nov '15

linearscan[1] is a linear scan register allocator[2], written in Coq[3], and extracted to Haskell, as a library for Haskell programs that need to allocate registers. It may also be used directly from Coq. This project is the result of a year-long effort, funded by BAE Systems[4], to explore the application of dependent-types and mathematical verification to a typical engineering task. During the course of construction, several hundred theorems about the code were proven -- although exhaustive coverage was not, in the end, achievable given our time constraints. To remedy this, and as a test of the extraction to Haskell, an optional runtime verifier was built to certify the resulting allocations. Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that version[7]. linearscan further relies on another library, coq-haskell[8], that I created to facilitate inter-operation between Haskell and Coq. For those using Hoopl[9] to represent program graphs, incorporating linearscan is quite easy: provide an instance of NodeAlloc using the linearscan-hoopl[10] library. Examples of doing so are provided in the test suite for that library. The allocation algorithm implemented by this library was first written in Java by Hanspeter Mössenböck and Michael Pfeiffer[11], and later improved upon by Christian Wimmer[12], whose master's thesis provided the specification for our implementation. John Wiegley BAE Systems Footnotes: [1] http://hackage.haskell.org/package/linearscan [2] http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf [3] https://coq.inria.fr/ [4] http://www.baesystems.com/en-us/our-company/inc-businesses/electronic-syste… [5] https://coq.inria.fr/news/125.html [6] http://ssr.msr-inria.inria.fr/ [7] http://ssr.msr-inria.inria.fr/FTP/ [8] https://github.com/jwiegley/coq-haskell [9] https://hackage.haskell.org/package/hoopl [10] http://hackage.haskell.org/package/linearscan-hoopl [11] http://dl.acm.org/citation.cfm?id=647478.727924 [12] http://www.christianwimmer.at/Publications/Wimmer04a/

1 0

Expanding the Core Libraries Committee
by Edward Kmett 13 Nov '15

13 Nov '15

At present the core libraries committee consists of 7 members: 6 regular members and one ex-officio appointment for the Haskell Platform maintainer. https://wiki.haskell.org/Core_Libraries_Committee The size of this committee was originally selected to be in line with the size of the extant haskell.org committee. During a meeting of the committee last week, we decided it is a bit too small to fulfill the function of adequately representing the broader community while still providing a sufficient institutional memory. Consequently, we've resolved to replace the current Haskell Platform maintainer appointment with 3 additional seats on the committee. This will grow the committee to 9 members. Pleased be advised, membership on the committee is a commitment to a fairly active role. For more information on some the processes surrounding the core libraries, please see the library submissions page on the Haskell wiki: https://wiki.haskell.org/Library_submissions If you are interested in self-nominating for the core libraries committee, please send an email to core-libraries-committee(a)haskell.org. Thank you for your time and consideration. -Edward Kmett Core Libraries Committee Chair

1 0

Conditionally add OpenBSD's pledge(2) call -- but to which library?
by Matthias Kilian 12 Nov '15

12 Nov '15

Hi, I'd like to add the (OpenBSD only) pledge(2) call to some library in our (OpenBSD's) ghc port. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=… and http://www.openbsd.org/papers/hackfest2015-pledge/index.html for some information of what this is about (and Linux people, please don't feel too offended by that second one ;-)) I'd to this as a patch to ghc in our port, but I'd like to eventually submit a patch to include it (conditionally, only on OpenBSD for now) upstream. But I need some hints *where* to include it. At the moment, I'm considering the unix package (bundled with ghc), and therein, the module System.Posix.Unistd. Even if pledge(2) obviously isn't Posix, it's all about stripping down an API which in large parts conforms to Posix to some subset. Would this be acceptable? Or should I use something like System.OpenBSD.Unistd? In any case, client application using it would always either need some #ifdef or would get patches local to the OpenBSD ports tree. So, any thoughts about this? Please note: just writing a separate package for this wouldn't help much (for OpenBSD ports), because it would require changing cabal dependencies for every client application in addition to other source code patches. Ciao, Kili

4 4