- Libraries - Haskell.org

Since notice in instance declarations.
by Oleg Grenrus 06 Oct '15

06 Oct '15

Dear all, What you think, if instead of /Since: 4.8.0.0/, we start to use /Since: base-4.8.0.0/. Adding the package name seems redundant, but on the other hand some haddock instance lists look weird. For example in Cabal Distribution.Version docs [1] has: NFData Version -- /Since: 1.3.0.0/ Luckily Cabal is in 1.2x, otherwise /Since: 1.3.0.0/ next to the NFData Version could be very confusing. What you think about this new practice? Greetings, Oleg Grenrus [1] http://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Version… <http://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Version…> P.S. also the [1] doesn’t show orphan `Binary Version` instance provided. I hope it was a temporary glitch in haddock.

2 2

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Sven Panne 06 Oct '15

06 Oct '15

2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson(a)kent.ac.uk>: > [...] It’s really interesting to have this discussion, which pulls in all > sorts of well-made points about orthogonality, teaching, the evolution of > the language and so on, but it simply goes to show that the process of > evolving Haskell is profoundly broken. [...] > I wouldn't necessarily call the process "broken", but it's a bit annoying: Because of the constant flux of minor changes in the language and the libraries, I've reached the stage where I'm totally unable to tell if my code will work for the whole GHC 7.x series. The only way I see is doing heavy testing on Travis CI and littering the code with #ifdefs after compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No clue how to do that...) This is less than satisfactory IMHO, and I would really prefer some other mode for introducing such changes: Perhaps these should be bundled and released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way some stuff which belongs together (AMP, FTP, kicking out return, etc.) comes in slightly larger, but more sensible chunks. Don't get me wrong: Most of the proposed changes in itself are OK and should be done, it's only the way they are introduced should be improved...

9 8

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Dominic Steinitz 05 Oct '15

05 Oct '15

> The upshot of this e-mail is a strong collective -2 > from us both on particular proposal, and a general call > for much more caution when it comes to breaking changes > that are not critically important. Thank you for articulating what are also my misgivings. -1 from me also. On a historical note `return` used to be called `unit`. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

6 5

updating stream-fusion for GHC-7.10
by Henning Thielemann 05 Oct '15

05 Oct '15

Attached is a patch to the stream-fusion package that makes it compileable by GHC-7.10. Unfortunately the authors did not reply to my patch request. How can I get the patch into the package?

3 2

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Malcolm Wallace 05 Oct '15

05 Oct '15

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. Regards, Malcolm > On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: > >> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits. >> >> Regards, >> Malcolm >> >> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >> >>> Hi all, >>> >>> I have discussed the monad of no return proposal with >>> my colleague Graham Hutton: a long-standing member of >>> the Haskell community, well-known researcher, some 20 >>> years of experience of teaching Haskell to >>> undergraduate students, and author of one of the most >>> successful introductory Haskell textbooks there are. >>> >>> The upshot of this e-mail is a strong collective -2 >>> from us both on particular proposal, and a general call >>> for much more caution when it comes to breaking changes >>> that are not critically important. >>> >>> First, on a general note, there has recently been a >>> flurry of breaking changes to the (de facto) Haskell >>> standards. In many cases for very good reasons, but >>> sometimes it seems more in a quest for perfection >>> without due consideration for the consequences. It used >>> to be the case that breaking changes were very rare >>> indeed. And for good reason. >>> >>> Right now, the main "measure of breakage" in the >>> on-line discussions seems to be how many packages that >>> break in Hackage. Which of course makes sense: the >>> Hackage repository is very important and such a measure >>> is objective, as far as it goes. >>> >>> But we should not forget that breakage can go far >>> beyond Hackage. For starters, there is *lots* of code >>> that is not in Hackage, yet critically important to its >>> users, however many or few they are. There are more >>> than hundreds of thousands of copies of books out there >>> where that may break in that examples may no longer >>> work. And they cannot be changed. There are countless >>> research papers that may break in the same way. Every >>> single institution that use Haskell in their teaching >>> may have to update their teaching materials (slides, >>> code, lab instructions) for every module that teaches >>> or uses Haskell. And last but not the least, what >>> countless of programmers and students have learned >>> about Haskell over decades, most of whom are *not* >>> power users who can take these changes in their stride, >>> may also break. >>> >>> Now, of course a language has to evolve, and sometimes >>> breaking backwards compatibility is more or less >>> essential for the long-term benefit of the language. >>> But we should not let perfection be the enemy of the >>> good. >>> >>> As to this particular proposal, the monad of no return, >>> it does not seem essential to us, but mostly motivated >>> by a quest for "perfection" as defined by a very >>> knowledgeable but in relative terms small group of >>> people. >>> >>> One argument put forward was that applicative code that >>> uses "return" instead of "pure" should get a less >>> constrained type. But such code is relatively new. The >>> methods of the Monad class have been return and bind >>> for some 25 years. So indeed, as Henning Thielemann >>> wrote: why should not the newer code be adapted and use >>> "pure" instead? In fact, the use of "pure" in such code >>> could serve as a quite useful cue that the code is >>> applicative rather than monadic, especially where >>> applicative do is employed. >>> >>> Another reason put forward is support for the >>> applicative do syntax. But that is, in standard terms, >>> only a future possibility at this point. Further, the >>> syntax is arguably rather dubious anyway as it, in >>> particular to someone with an imperative background, >>> suggests a sequential reading which is exactly what >>> applicative is not and why it is useful. So from that >>> perspective, using the applicative operators directly, >>> without any syntactic sugar, actually amounts to a much >>> more transparent and honest syntax, even if a bit more >>> verbose in some cases. >>> >>> The bottom line is that it is premature to put forward >>> support for the applicative do syntax as a rationale >>> for a non-essential breaking change. >>> >>> Best regards, >>> >>> Henrik Nilsson and Graham Hutton >>> >>> -- >>> Henrik Nilsson >>> School of Computer Science >>> The University of Nottingham >>> nhn(a)cs.nott.ac.uk >> >

2 1

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Thomas Miedema 04 Oct '15

04 Oct '15

> > > So there's not that much immediate breakage due to MRP specifically after > > all. > > Then count me again as +1, thanks for the clarification, Herbert. > +1 as well - The books are already outdated. Libraries can be updated. - This proposal simplifies the language and the next Haskell report.

1 0

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Andrés Sicard-Ramírez 04 Oct '15

04 Oct '15

Hi, In Agda, we added support for GHC 7.10.* following the migration guide available at https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 In particular, we added instances of Applicative using instance Applicative Foo where pure = return (<*>) = ap -- defined in Control.Monad After reading the "Monad of no `return` proposal" below, I have two questions: 1. Shouldn't the above migration guide to be changed to something like instance Applicative Foo where pure = <copy-the-definition-of-return> ... instance Monad Foo where return = pure ? 2. Since in Agda code `return` is used everywhere, does follow (1) has some performance cost? All the best, On 24 September 2015 at 16:43, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > 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 > > -- > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Andrés

2 1

Can we simplify Dynamic?
by David Feuer 02 Oct '15

02 Oct '15

Currently, data Dynamic = Dynamic TypeRep Obj deriving Typeable where type Obj = Any As a result, all of the operations must be implemented "by hand" using unsafeCoerce. The more obvious representation these days would seem to be data Dynamic where Dynamic :: Typeable a => a -> Dynamic Most of the operations then become trivial applications of Typeable functions. The only exceptions seem to be dynApply and dynApp. That there are exceptions strikes me as quite unfortunate. The easiest fix is inspired by the fact that Data.Dynamic uses funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep from Data.Typeable to decide whether to coerce. It seems reasonable to add a more informative version, something like applyTypeable :: (Typeable f, Typeable a) => proxy f -> proxy a -> (forall b . (Typeable b, f ~ (a -> b)) => r) -> Maybe r On the other hand, it would be really cool if there were some more general way to get type-level information out of Typeable instances, pattern matching on the type constructors.

5 9

[unix] POSIX Message Queue support
by Elliot Robinson 01 Oct '15

01 Oct '15

We've had a request for info regarding message queue support in `unix` [0]. The related headers are currently listed in `System/Posix.hs` under the "Unsupported interfaces" category. Is the community aware of a reason that we have chosen not to support this interface going forward, or is this an artifact from when the library was originally ported (late 2002 by Simon Marlow) which we can now ignore? -- Elliot Robinson GPG Key: 9FEDE59A [0] https://github.com/haskell/unix/issues/47

1 0

Proposal: Derive Lift for all data types in the template-haskell library
by Ryan Scott 26 Sep '15

26 Sep '15

The DeriveLift extension has landed in GHC HEAD, so now it's become apparent that the bikeshed needs a new coat of paint. The only Lift instances at the moment are base types [1], but with DeriveLift, it would be possible to implement Lift for many for data types with ease. I'll make (what I hope is) an uncontroversial first suggestion: we should derive Lift for every data type in the template-haskell library itself. These instances have proved to be useful for library authors who need to convert to and from the TH AST (th-desugar, for example, relies on this functionality via orphan instances [2]). Adding this would break some code out in the wild (the th-lift [3] and th-orphans [4] packages come to mind; there may be others), so I'll request feedback before marching forth with this proposal. Ryan S. ----- [1] http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-… [2] http://hackage.haskell.org/package/th-desugar-1.5.4.1/docs/src/Language-Has… [3] http://hackage.haskell.org/package/th-lift [4] http://hackage.haskell.org/package/th-orphans

3 4