October 2015 - Libraries

ANNOUNCE: unordered-graphs
by Ivan Lazar Miljenovic 09 Oct '15

09 Oct '15

I have a relatively hacked-together graph library that uses unordered-containers as a backend available if anyone finds it interesting/useful: http://hackage.haskell.org/package/unordered-graphs It's primarily developed just for my own needs and thus I'm not sure how much future work I'll be doing on it, but I'm willing to accept pull requests. This library was semi-experimental in that I also tried a few things out with it: * Polymorphic node type * Fixed auto-generated edge type: this is because (node,node, label) triples (ala fgl) do not provide sufficient information to be able to distinguish between multiple edges, etc. * Type parameter to determine whether the graph is directed or undirected. * Typeclass to allow you to determine the type/output of a a match (I didn't end up actually using this, as the one time I needed to do a match I found the extra polymorphism caused problems; it also isn't comprehensive as I didn't write all that many instances.) -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: status and future of haskell98 and haskell2010 packages
by Herbert Valerio Riedel 08 Oct '15

08 Oct '15

On 2015-10-08 at 00:08:43 +0200, Andrey Chudnov wrote: > My e-mail was rejected from libraries(a)haskell.org (the official > maintenance contact of the two packages in question), so I'm trying my > luck here instead. Hoping I can get some answers on the following > questions: > > 1. What is the status of `haskell2010` and `haskell98` packages? Are > they supported? Deprecated? In need of new maintainers? Short answer: with GHC 7.10 it is not possible anymore to implement a proper[1] `haskell98` or `haskell2010` package anymore. More details can be found at https://ghc.haskell.org/ticket/9590 > 2. Assuming the answer to the previous question is "alive and well", > are there any plans to release new versions of those for GHC 7.10 and > beyond? In order to be able to recover support for a `haskell2010` package in newer GHCs, GHC will need to be extended in some way. I can think of two different paths to pursue to accomplish this, depending on whether type(classes) need to be shared with `base` or not. Moreover, it wasn't clear how much actual demand there really is to have the recent GHCs support a legacy `haskell2010` mode. So if there's somebody interested in resuscitating a `haskell98`/`haskell2010` package, please tell us what your use-case is (to help understand whether type(class) sharing w/ `base` is essential or not -- it's *much* more easier to get this working w/o the typeclass sharing requirement, whereas the typeclass-sharing variant might not even be possible at all) Cheers, hvr [1]: I.e. with the requirement that all code written conforming to the respective Haskell Report will be compileable via e.g. ghc -XHaskell2010 -hide-all-packages -package haskell2010 -c *.hs (to some degree, this was already broken before GHC 7.10 due to the superclass-removal on `Num`, but with AMP this was broken beyond tolerance)

1 0

Proposal: pare down traversable
by David Feuer 07 Oct '15

07 Oct '15

Traversable currently has traverse, sequenceA, sequence, and mapM methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest that sequenceA be turned into a deprecated function and mapM be moved from Control.Monad to Data.Traversable and re-exported from Control.Monad. I expect most instance declarations to survive unchanged. The only CPP pain point will be that instances that define sequenceA will have to define sequence instead.

5 7

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Brandon Allbery 07 Oct '15

07 Oct '15

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

3 2

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Johan Tibell 07 Oct '15

07 Oct '15

(Resending with smaller recipient list to avoid getting stuck in the moderator queue.) On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > > On the libraries I maintain and have a copy of on my computer right now: > 329 > > > Although this was already pointed out to you in a response to a Tweet of > yours, I'd like to expand on this here to clarify: > > > You say that you stick to the 3-major-ghc-release support-window > convention for your libraries. This is good, because then you don't need > any CPP at all! Here's why: > > [...] > So what do I have to write today to have my Monad instances be: * Warning free - Warnings are useful. Turning them off or having spurious warnings both contribute to bugs. * Use imports that either are qualified or have explicit import lists - Unqualified imports makes code more likely to break when dependencies add exports. * Don't use CPP. Neither AMP or MRP includes a recipe for this in their proposal. AMP got one post-facto on the Wiki. It turns out that the workaround there didn't work (we tried it in Cabal and it conflicted with one of the above requirements.) PS: I'm a bit disappointed you seem to dismiss this proposal right away > categorically without giving us a chance to address your > concerns. The proposal is not a rigid all-or-nothing thing that > can't be tweaked and revised. That's why we're having these > proposal-discussions in the first place (rather than doing blind > +1/-1 polls), so we can hear everyone out and try to maximise the > agreement (even if we will never reach 100% consensus on any > proposal). > > So please, keep on discussing! > The problem by discussions is that they are done between two groups with quite a difference in experience. On one hand you have people like Bryan, who have considerable contributions to the Haskell ecosystem and much experience in large scale software development (e.g. from Facebook). On the other hand you have people who don't. That's okay. We've all been at the latter group at some point of our career. What's frustrating is that people don't take a step bad and realize that they might be in the latter group and should perhaps listen to those in the former. This doesn't happen, instead we get lots of "C++ and Java so bad and we don't want to be like them." Haskell is not at risk of becoming C++ or Java (which are a large improvement compared to the languages came before them). We're at risk of missing our window of opportunity. I think that would be a shame, as I think Haskell is a step forward compared to those languages and I would like to see more software that used be written in Haskell. We've been through this many times before on the libraries list. I'm not going to win an argument on this mailing list. Between maintaining libraries you all use and managing a largish team at Google, I don't have much time for a discussion which approaches a hundred emails and is won by virtue of having lots of time to write emails. -- Johan

4 4

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 05 Oct '15

05 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