Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
143 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Simon  Thompson
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.

If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There’s an old fashioned maxim that sums this up in a pithy way: “if it ain’t broke, don’t fix it”.

Simon Thompson



On 5 Oct 2015, at 10:47, Michał J Gajda <[hidden email]> wrote:

Hi,

As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change:
1. Orthogonal type classes are easier to explain.
2. Gradual improvements helps us to generalize further, and this in turn makes education easier.
3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited.

That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own.

So:
+1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library.

That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability?

PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral".
--
  Best regards
    Michał

On Monday, 5 October 2015, Malcolm Wallace <[hidden email]> wrote:
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 
(...) 


--
  Pozdrawiam
    Michał
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Simon Thompson | Professor of Logic and Computation 
School of Computing | University of Kent | Canterbury, CT2 7NF, UK
[hidden email] | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Mario Blažević
On 15-10-05 05:59 AM, Simon Thompson wrote:
> Hello all. I write this to be a little provocative, but …
>
> ...
> Other languages do evolve, but in a managed and reflective way.

Citation needed.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Sven Panne-2
In reply to this post by Simon Thompson
2015-10-05 11:59 GMT+02:00 Simon Thompson <[hidden email]>:
[...] 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...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

mantkiew
Well, there are the *compat packages:

Base-compat
Transformers-compat
Mtl-compat 

Etc. They do centralize the ifdefs and give you compatibility with ‎GHC 7.*. I recently adopted the last two ones and they work like a charm. I am yet to adopt base-compat, so I don't know what the experience is with it. 

Michał

From: Sven Panne
Sent: Monday, October 5, 2015 9:27 AM
To: Simon Thompson
Cc: Michał J Gajda; [hidden email] List; Haskell Libraries; haskell cafe; Graham Hutton
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

2015-10-05 11:59 GMT+02:00 Simon Thompson <[hidden email]>:
[...] 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...


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Gershom Bazerman
In reply to this post by Simon Thompson
On October 5, 2015 at 6:00:00 AM, Simon Thompson ([hidden email]) 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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Herbert Valerio Riedel
In reply to this post by Sven Panne-2
On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:

> 2015-10-05 11:59 GMT+02:00 Simon Thompson <[hidden email]>:
>
>> [...] 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...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API).  One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!



 [1]: IMO, we need something to be used at the definition site providing
      desugaring rules, rather than requiring the use-site to enable a
      generalised desugaring mechanism; I've been told that Agda has an
      interesting solution to this in its base libraries via
      {-# LANGUAGE BUILTIN ... #-} pragmas.


Regards,
  H.V.Riedel
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Bryan O'Sullivan
In reply to this post by Gershom Bazerman
I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed – and to general approval, no less – on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.

I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.

Thanks,
Bryan.

> On Oct 5, 2015, at 7:32 AM, Gershom B <[hidden email]> wrote:
>
>> On October 5, 2015 at 6:00:00 AM, Simon Thompson ([hidden email]) 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.
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Gershom Bazerman
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,  
> and lecture notes should be very high; and that the benefit associated with such a breaking  
> change should be correspondingly huge.
>  

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Johan Tibell-2
Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <[hidden email]> wrote:
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,
> and lecture notes should be very high; and that the benefit associated with such a breaking
> change should be correspondingly huge.
>

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Henning Thielemann

On Mon, 5 Oct 2015, Johan Tibell wrote:

> Perhaps we should weigh the +1 and -1s in this thread with the number of
> lines of Haskell written by the voter? ;)

My prefered measure would the number of Haskell packages hosted at
hub.darcs.net. :-)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Dimitri DeFigueiredo
In reply to this post by Johan Tibell-2
+1

I think this idea is good and should not be taken lightly. I'm a newcomer to the community and currently hold a grand total of *zero* open source contributions. Obviously, I would like to change this soon, but I think it is very *unfair* and makes absolutely no sense to have the standard one person one vote rule for decisions involving the libraries.

Let the code produced vote. Maybe weight them by downloads?

Dimitri



On 10/5/15 9:12 AM, Johan Tibell wrote:
Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <[hidden email]> wrote:
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,
> and lecture notes should be very high; and that the benefit associated with such a breaking
> change should be correspondingly huge.
>

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

John Lato-2

I think code-based weighting should not be considered at all. There's a non-trivial amount of proprietary code that wouldn't be counted, and likely can't be accounted for accurately. I have some unknown amount of code at my previous employer (which does include Monad instances) that now has to be maintained by others. I may have said +1 (and I'm reconsidering), but the current maintainers probably don't want the extra make-work this involves.

There's an argument that this proposal involves very little up-front breakage. This is true but disingenuous, because the breakage will still happen in the future unless changes are made and committed. The entire maintenance load should be considered, not just the immediate load.

Bryan, nothing I've seen since I started using Haskell makes me think that the libraries committee or ghc devs value back compatibility much at all.  My favorite example is RecursiveDo, which was deprecated in favor of DoRec, only for that to be reversed in the next ghc release. Of course that was more irritating than breaking, but it's indicative of the general value placed on maintenance programming.


On 12:28, Mon, Oct 5, 2015 Dimitri DeFigueiredo <[hidden email]> wrote:
+1

I think this idea is good and should not be taken lightly. I'm a newcomer to the community and currently hold a grand total of *zero* open source contributions. Obviously, I would like to change this soon, but I think it is very *unfair* and makes absolutely no sense to have the standard one person one vote rule for decisions involving the libraries.

Let the code produced vote. Maybe weight them by downloads?

Dimitri




On 10/5/15 9:12 AM, Johan Tibell wrote:
Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <[hidden email]> wrote:
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,
> and lecture notes should be very high; and that the benefit associated with such a breaking
> change should be correspondingly huge.
>

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Gregory Collins-3
In reply to this post by Gershom Bazerman

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <[hidden email]> wrote:
My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ  find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

G
--
Gregory Collins <[hidden email]>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Nathan Bouscal
In reply to this post by Dimitri DeFigueiredo
I'm a strong +1 on this (and on Edward's addendum to it), and I object to the characterization of this change as having only trivial benefits. Simplicity and correctness are never trivial. In my view, disagreement on how this change is made (migration strategy, etc.) is completely reasonable, but disagreement on whether to make it is not.

There have been a lot of objections based on the idea that learners will consult books that are out of date, but the number of learners affected by this is dwarfed by the number of learners who will use updated materials and be confused by this strange historical artifact. Permanently-enshrined historical artifacts accrete forever and cause linear confusion, whereas outdated materials are inevitably replaced such that the amount of confusion remains constant.

There was also an argument that Haskell has a “window of opportunity”, implying that breakages are more likely to cost us future valued community members than historical artifacts are. I couldn't disagree more. If it weren't for Haskell's past willingness to make changes when we learned better ways of doing things, I doubt I would presently be using the language. I would much rather add a marginal community member with a strong preference for cleanliness, simplicity, and correctness than one with a strong preference against making occasional small changes to their code.

On Mon, Oct 5, 2015 at 6:28 PM, Dimitri DeFigueiredo <[hidden email]> wrote:
+1

I think this idea is good and should not be taken lightly. I'm a newcomer to the community and currently hold a grand total of *zero* open source contributions. Obviously, I would like to change this soon, but I think it is very *unfair* and makes absolutely no sense to have the standard one person one vote rule for decisions involving the libraries.

Let the code produced vote. Maybe weight them by downloads?

Dimitri




On 10/5/15 9:12 AM, Johan Tibell wrote:
Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <[hidden email]> wrote:
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,
> and lecture notes should be very high; and that the benefit associated with such a breaking
> change should be correspondingly huge.
>

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Sven Panne-2
In reply to this post by Gershom Bazerman
2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
[...] As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. [...]

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Johan Tibell-2
In reply to this post by Gregory Collins-3
On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <[hidden email]> wrote:

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <[hidden email]> wrote:
My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ  find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

On the libraries I maintain and have a copy of on my computer right now: 329


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Erik Hesselink
In reply to this post by Sven Panne-2
On 5 October 2015 at 20:58, Sven Panne <[hidden email]> wrote:

> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>>
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

Erik

[1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Johan Tibell-2
On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink <[hidden email]> wrote:
On 5 October 2015 at 20:58, Sven Panne <[hidden email]> wrote:
> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>>
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

No it doesn't, if you also don't want closed import lists (which you should).
 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Christopher Allen
In reply to this post by Johan Tibell-2
I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to date with GHC 7.10. AMP made things better, not harder, with respect to teaching Haskell. BBP required some explanation of "ignore this type, we're asserting a different one", but the positives are still better than the negatives.

Please don't use existing or forthcoming books as an excuse to do or not-do things. Do what's right for the users of the language.

On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell <[hidden email]> wrote:
On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <[hidden email]> wrote:

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <[hidden email]> wrote:
My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ  find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

On the libraries I maintain and have a copy of on my computer right now: 329


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries




--
Chris Allen
Currently working on http://haskellbook.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Marcin Mrotek
In reply to this post by John Lato-2
> There's an argument that this proposal involves very little up-front
> breakage. This is true but disingenuous, because the breakage will still
> happen in the future unless changes are made and committed. The entire
> maintenance load should be considered, not just the immediate load.

I don't have much to say about breakage (and thus I've refrained from
voting), as a maintainer of just 7 packages of which exactly zero are
compatible with anything else than the latest GHC (well, no one
complained, I'm rather lazy, and if it's any defense I can't even run
GHC 7.10.1 on my Arch Linux box because of inappropriate versions of
dynamically linked libraries), but a honest question: does this
proposal entail anything else than replacing every "return" with
"pure" and conditional compilation of "return = pure" in Monad
instances?

Best regards,
Marcin Mrotek
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
1234 ... 8