Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

newer
Breaking Changes and Long Term...

older
Default definition for fromRational

Gregory Collins

5 Oct 2015 5 Oct '15

8:40 p.m.

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter 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

Attachments:

attachment.html (text/html — 2.3 KB)

Show replies by date

Ivan Lazar Miljenovic

6 Oct 6 Oct

3:04 a.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On 6 October 2015 at 11:40, Gregory Collins wrote:

...

defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik)

http://hackage.haskell.org/package/time-locale-compat -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Bardur Arantsson

3:40 a.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On 10/06/2015 02:40 AM, Gregory Collins wrote:

...

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter 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

Having code meant for 4 different versions of a compiler be completely -Wall clean is not a reasonable goal. This doesn't even happen for C++ compilers! (If my experience is anything to go by.) It's also the reason -Werror is forbidden in Hackage uploads. (At least, I think it is. Isn't it?) Also, GHC 7.4 was released 2½ years ago. You may have my sympathies for trying to support it, but unless you're getting paid for it I don't think it's reasonable to expect you to. (If you're getting paid, then I don't understand the complaint -- it might be a bit of make-work, but I think everybody is subjected to that.)

...

- defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik)

"time-locale-compat" as Ivan pointed out.

...

- one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc)

I think these were because people learned that they could be done better? (Also, I believe there was something here about these changes being necessary for Safe Haskell, namely forbidding user-written instances?) Is Typeable part of Haskell 2010?

...

- 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)

Could you solve it with a qualified import? Then why use CPP? (Incidentally, I think this is evidence that the Prelude should be an explicit import like in PureScript.)

...

- 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

You don't *have* to shut up all warnings. (Unless we're talking deprecation warnings *and* you're getting close to the cutoff point.)

...

- ==# and friends return Int# instead of Bool after GHC 7.8.1

Hoogle find ==# (and I've never heard it of before).

...

- 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)

Well, yeah, new functions don't magically appear in old versions. I don't anybody expects that :). Regards,

Tom Ellis

4:36 p.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:

...

- defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik)

http://hackage.haskell.org/package/time-compat

Tom Ellis

4:39 p.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:

...

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter 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)

In fact I think all of these apart from the FFI one could be solved with a -compat package, could they not?

Gregory Collins

5:29 p.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

...

In fact I think all of these apart from the FFI one could be solved with a -compat package, could they not?

Who cares? In practice, the programs break and I have to fix them. Most of the time, CPP is the lowest-friction solution -- if I rely on a -compat package, first I have to know it exists and that I should use it to fix my compile error, and then I've added an additional non-platform dependency that I'm going to have to go back and clean up in 18 months. Usually, to be honest, *actually* the procedure is that the new RC comes out and I get github pull requests from hvr@ :-) :-) In response to the other person who asked "why do you want to support so many GHC versions anyways?" --- because I don't hate my users, and don't want to force them to run on the upgrade treadmill if they don't have to? Our policy is to support the last 4 major GHC versions (or 2 years, whichever is shorter). And if we support a version of GHC, I want our libraries to compile on it without warnings, I don't think that should mystify anyone. -- Gregory Collins

José Manuel Calderón Trilla

6:56 p.m.

New subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Hello all, I agree with Henrik, I'm very keen on giving the new Haskell committee a shot. While some may not think that Haskell2010 was a success, I think it would be difficult to argue that Haskell98 was anything but a resounding success (even if you don't think the language was what it could have been!). Haskell98 stabilized the constant changes of the proceeding 7 years. The stability brought with it books and courses, and the agreed-upon base of the language allowed _research_ to flourish as well. Having an agreed base allowed the multiple implementations to experiment with different methods of implementing what the standard laid out. Many of us here learned from those texts or those courses. It's easy online to say that materials being out of date isn't a big deal, but it can turn people off the language when the code they paste into ghci doesn't work. We use Haskell for the compilers course at York; Haskell is the means, not the end, so having to update the materials frequently is a significant cost. It can be difficult to defend the choice of using Haskell when so much time is spent on something that 'isn't the point' of the course. Does that mean that we should never change the language? Of course not, but this constant flux within Haskell is very frustrating. Maybe Haskell2010 wasn't what everyone wanted it to be, but that does not mean the _idea_ of a committee is without merit. Having controlled, periodic changes that are grouped together and thought through as a coherent whole is a very useful thing. One of the insights of the original committee was that there would always be one chair at any point in time. The chair of the committee had final say on any issue. This helped keep the revisions coherent and ensured that Haskell made sense as a whole. Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago when the issue of incompatible changes came up. His thoughts were similar to Johan's: On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote:

...

As a practical suggestion, if any changes for version 1.3 could make some revision of a 1.2 programs necessary, let's have a precise stand-alone specification of these revisions and how to make them. It had better be short and simple. Many would prefer it to be empty. Perhaps it should be implemented in Haskell compilers?

Overall I don't see the rush for these changes, let's try putting our faith in a new Haskell committee, whomever it is comprised of. Best wishes, José Manuel P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I was studying his thesis. I was able to run the code without issue, allowing me to be more productive in my research ;-) On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins wrote:

...

On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

...
In fact I think all of these apart from the FFI one could be solved with a -compat package, could they not?

Who cares? In practice, the programs break and I have to fix them. Most of the time, CPP is the lowest-friction solution -- if I rely on a -compat package, first I have to know it exists and that I should use it to fix my compile error, and then I've added an additional non-platform dependency that I'm going to have to go back and clean up in 18 months. Usually, to be honest, *actually* the procedure is that the new RC comes out and I get github pull requests from hvr@ :-) :-)

In response to the other person who asked "why do you want to support so many GHC versions anyways?" --- because I don't hate my users, and don't want to force them to run on the upgrade treadmill if they don't have to? Our policy is to support the last 4 major GHC versions (or 2 years, whichever is shorter). And if we support a version of GHC, I want our libraries to compile on it without warnings, I don't think that should mystify anyone.

-- Gregory Collins

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

18 Oct 18 Oct

2:49 p.m.

New subject: How to avoid CPP (Was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On Mon, 5 Oct 2015, Gregory Collins wrote:

...

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

I import them qualified and then define type CInt = CTypes.CInt sometimes.

...

* defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik)

I was advised to always import time-1.5.

...

* one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc)

I have not used that. Like I have not used the ever changing Template Haskell stuff.

...

* 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)

I think System.IO.Error.catchIOError maintains the old behaviour.

...

* 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

I always import them from the most specific module. Where GHC-7.10 Prelude causes conflicts I even started to import more basic Prelude stuff from modules like Data.Bool, Data.Eq and friends. Horrible, but works without CPP.

...

* ==# and friends return Int# instead of Bool after GHC 7.8.1

I did not use it. I have also warned that the change might not be a good idea since LLVM knows that its 'i1' type can only have the values 0 and 1 and it does not know that for 'i32' or 'i64'.

...

* 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)

I have not used them so far. I have solved more complicated cases with conditional Hs-Source-Dirs: http://wiki.haskell.org/Cabal/Developer-FAQ#Adapt_to_different_systems_witho... It's cumbersome but so far I managed most transitions without CPP. (Nonetheless, MRP would require the complicated Hs-Source-Dirs solution for far too many packages.)

3503

Age (days ago)

3515

Last active (days ago)

List overview

Download

7 comments

6 participants

participants (6)

Bardur Arantsson
Gregory Collins
Henning Thielemann
Ivan Lazar Miljenovic
José Manuel Calderón Trilla
Tom Ellis

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

tags

participants (6)