- Libraries - Haskell.org

Taking a step back
by Johan Tibell 11 Nov '15

11 Nov '15

Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

21 28

[cabal] Extract simple static information from PackageDescription
by Jakob Schöttl 07 Nov '15

07 Nov '15

Hello, I have a simple question regarding GenericPackageDescription/ PackageDescription. I don't understand it from the docs: https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Packag… Google and IRC #haskell also didn't help me. I am trying to extract a simple static information out of the cabal file: the hs-source-dirs Is there a way to get this without resolving conditionals, or with minimal effort? (I don't even understand how to resolving conditionals.) I tried it like this: https://gist.github.com/schoettl/b321baa5002ca48a46c5 But here the PackageDescription has no information (library == Nothing, executables == []). I appreciate any help so much. And I will release the program as an open-source example so that it may help other people in future. Thank you, Jakob -- Jakob Schöttl E-Mail: jschoett(a)gmail.com PGP-Key: 0x25055C7F http://jakob.keramik-schoettl.de

3 5

Proposal: Dot as Postfix Function Apply
by Jeremy 06 Nov '15

06 Nov '15

Dot as Postfix Function Apply (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField…) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax. The idea is that instead of (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) we could have person.title ++ " " ++ person.firstName ++ " " ++ person.lastName This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are: 1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing . This would be an opt-in extension. I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

18 27

3 release policy
by Jeremy 04 Nov '15

04 Nov '15

A "3 release policy" has been recently mentioned several times, whereby it should always be possible to write code that compiles with the last three releases of GHC, without generating any -Wall warnings. The no warning requirement seems excessively harsh. Will early warnings of impending breakage really cause so much trouble that accepted proposals have to be dragged out over several years to avoid them? If so, would a flag to suppress the warnings suffice? I should note that GHC has traditionally had no qualms about introducing new warnings, on by default. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

17 18

Re: process package with compilers besides GHC
by Malcolm Wallace 03 Nov '15

03 Nov '15

Clean-up is generally good. I have not maintained any Haskell compiler for about 5 years now, so I think it is safe to say you can go ahead. nhc98 did indeed build the 'process' package as part of its library set, but most recently at version 1.0.1.4. Regards, Malcolm On 2 Nov 2015, at 16:21, Michael Snoyman wrote: > Forwarding directly to you, in case you're not reading the mailing lists. > > ---------- Forwarded message ---------- > From: Michael Snoyman <michael(a)snoyman.com> > Date: Mon, Nov 2, 2015 at 8:10 AM > Subject: process package with compilers besides GHC > To: Haskell Cafe <haskell-cafe(a)haskell.org>, libraries <libraries(a)haskell.org> > > > I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: > > 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers > 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC > > I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. > > * No pun intend >

1 0

process package with compilers besides GHC
by Michael Snoyman 02 Nov '15

02 Nov '15

I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. * No pun intend

3 2

Maintainership of cassava
by Christopher Allen 29 Oct '15

29 Oct '15

It wasn't listed in Johan's personal libraries he'd like to investigate personally and it's not part of CLC. Only uploader for the cassava package on Hackage at the moment is him. I pinged a week ago via email, no reply. Pinged on Twitter, no reply. Seems to be online (tweeted earlier today), but hasn't replied to any queries about the status of the library. Cheers, Chris Allen

1 0

Data.OldList
by Andrew Farmer 27 Oct '15

27 Oct '15

I was wondering what the plan for Data.OldList was. Is this just a transitional module for FTP-related migration, or can I count on it being maintained indefinitely? Thanks! Andrew

2 1

Add stricter accumulating map
by David Feuer 24 Oct '15

24 Oct '15

mapAccumL is a generally useful operation on Traversable containers. The only version currently offered uses (a copy of) lazy state to support streaming left-to-right consumption. This does not, however, seem terribly appropriate/efficient for other usage patterns (e.g., a FIFO queue with right view, or a Map). Could we add a version that uses a copy of Control.Monad.Trans.State.Strict to support those too?

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Gershom B 22 Oct '15

22 Oct '15

On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson(a)kent.ac.uk) wrote: > Hello all. I write this to be a little provocative, but … > > 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. > > Other languages do evolve, but in a managed and reflective way. Simply throwing in changes > that would have a profound impact on systems that are commercially and potentially safety > critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility > of the Haskell community to its users and, indirectly, to its future. Hi Simon. I do in fact think this is provocative :-P I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? —Gershom P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.

36 82