- Libraries - Haskell.org

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

Breaking Changes and Long Term Support Haskell
by Jeremy 21 Oct '15

21 Oct '15

There seems to be a fair amount of friction between those who want to introduce new features or fix significant historical warts in the base libraries - even if this requires breaking changes - and those who insist on no significant breaking changes in new releases, regardless of the reason or how much warning was given. The rest of the industry has already solved this with long-term/extended support releases. Some version of the platform is blessed with long-term support, and will continue to receive bug fixes and security patches for a number of years, but no other changes. This solution exists for Haskell as well, in the form of Long-Term Support Haskell (https://github.com/fpco/lts-haskell/blob/master/README.md) by FP Complete. Not only GHC but an entire ecosystem of libraries are frozen when a new LTS version is released and only bug/security fixes are allowed going forward. Users requiring long-term stability over new features could use LTS Haskell, while those who accept some fixing up of old code to gain new features (or remove old warts) can uses the latest GHC and Hackage. The only deficiency I can see in this is that FP Complete don't seem to provide any guarantees as to how long they will continue maintaining any LTS release. However, this is only relevant to bug fixes which tend to taper off after a while anyway - the actual release is available for perpetuity. Perhaps they could provide a commercial service with guarantees of bug-fixes for x years? -- View this message in context: http://haskell.1045720.n5.nabble.com/Breaking-Changes-and-Long-Term-Support… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Gregory Collins 18 Oct '15

18 Oct '15

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b(a)chreekat.net> wrote: > Hang on a moment, are you saying that all the people writing to argue > that these changes would require them to write dozens more #ifdef's > actually don't have to write any at all? > Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few years: - After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere - defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik) - one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc) - Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first place) - Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle - ==# and friends return Int# instead of Bool after GHC 7.8.1 - To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not older ones (this is a place where CPP use is actually justified) -- Gregory Collins <greg(a)gregorycollins.net>

6 7

Default definition for fromRational
by Joe Hermaszewski 15 Oct '15

15 Oct '15

A suitable default definition for fromRational could be the following: fromRational n = fromInteger (numerator n) / fromInteger (denominator n) Changing the MINIMUM pragma to just {-# MINIMAL recip | (/) #-} - Joe

2 1

Final Call for Haskell Prime language committee Nominations!
by Herbert Valerio Riedel 11 Oct '15

11 Oct '15

The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell Prime self-nominations (see also original CfN at [1]) is near! If you have already submitted a self-nomination, please make sure (if it was sent to the haskell-prime list) that it shows up in the mailing list archives at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

1 0