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

classic Classic list List threaded Threaded
243 messages Options
12345678 ... 13
Reply | Threaded
Open this post in threaded view
|

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

Marcin Mrotek
> I find this especially true in light of the recent advances made in the
> area of tooling. We are now in a much better position to be offering
> tools for automated refactoring than we were even when we considered
> AMP.

Well, it's not like this particular proposal requires tools any more
sophisticated than cut&paste (for instance declarations) and
search&replace (/return/pure/). The only code that will be negatively
affected is code that is not maintained or is printed on dead trees.

Best regards,
Marcin Mrotek
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
In reply to this post by Herbert Valerio Riedel
Strong +1 

this needs to happen. 

I'm ok with the migration overhead, and nows a good time to clean up these core things now that we understand what they should be / how they're interrelated. Most of the concerns i've seen seem to be a rehash of those from AMP and friends, which worked out pretty well I think! 

cheers!

On Thu, Sep 24, 2015 at 5:43 PM, Herbert Valerio Riedel <[hidden email]> wrote:
Hello *,

Concluding AMP and MFP, We (David and I) proudly present you the final
installment of the Monad trilogy:


Monad of no `return` Proposal
=============================

TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.


Current Situation
-----------------

With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and
(at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy
becomes


    class  Functor f  where
        fmap    :: (a -> b) -> f a -> f b


    class  Functor f => Applicative f  where
        pure    :: a -> f a
        (<*>)   :: f (a -> b) -> f a -> f b

        (*>)    :: f a -> f b -> f b
        u *> v  = …

        (<*)    :: f a -> f b -> f a
        u <* v  = …


    class  Applicative m => Monad m  where
        (>>=)   :: m a -> (a -> m b) -> m b

        return  :: a -> m a
        return  = pure

        (>>)    :: m a -> m b -> m b
        m >> k  = …


    class  Monad m => MonadFail m  where
        fail    :: String -> m a


Consequently, the `Monad` class is left with a now redundant `return`
method as a historic artifact, as there's no compelling reason to
have `pure` and `return` implemented differently.

Traditionally, `return` is often used where `pure` would suffice
today, forcing a `Monad` constraint even if a weaker `Applicative`
would have sufficed.

As a result, language extensions like `ApplicativeDo`[3] have to
rewrite `return` to weaken its `Monad m =>` constraint to
`Applicative m =>` in order to benefit existing code at the cost
of introducing magic behavior at the type level.

Finally, this redundancy becomes even more significant when viewed in
light of the renewed Haskell standardisation process[7]: The next
Haskell Report will almost certainly incorporate the AMP (and MFP)
changes, and there's no justification for the Report to retain
`return` as a method of `Monad`. A good reason would have been to
retain backward compatibility with Haskell 2010. However, as the AMP
superclass hierarchy requires `Monad` instances to be accompanied by
`Applicative` instances (which aren't part of Haskell 2010, c.f. [6]),
backward compatibility with Haskell 2010 goes out the window when it
comes to defining `Monad` instances (unless via use of `-XCPP` or
similar).  Consequently, meeting the high bar for a formal document
such as the Haskell Report demands that `Monad` shall not carry a
redundant `return` method that serves no purpose anymore. Moreover,
getting `return` out of the way is desirable to facilitate
standardising potential candidates such as the earlier mentioned
`ApplicativeDo` in the future and avoids the technical debt incurred
by keeping around this language wart.


Proposed Change
---------------

Remove `return` as a method from the `Monad` class and in its place
define a top-level binding with the weaker `Applicative` typeclass
constraint:


    -- | Legacy alias for 'pure'
    return :: Applicative f => a -> f a
    return = pure


This allows existing code using `return` to benefit from a weaker
typeclass constraint as well as cleaning the `Monad` class from a
redundant method in the post-AMP world.

A possible migration strategy is described further below.


Compatibility Considerations
----------------------------

Generalizing the type signature of a function from a `Monad`
constraint to its superclass `Applicative` doesn't cause new
type-errors in existing code.

However, moving a method to a top-level binding obviously breaks code
that assumes `return` to be a class method. Foremost, code that
defines `Monad` instances it at risk:

### Instance Definitions

Code defining `return` as part of an instance definition
breaks. However, we had the foresight to provide a default
implementation in `base-4.8` for `return` so that the following
represents a proper minimal instance definition post-AMP:


    instance Functor Foo where
        fmap g foo  = …

    instance Applicative Foo where
        pure x      = …
        a1 <*> a2   = …

    instance Monad Foo where
        m >>= f     = …

        -- NB: No mention of `return`


Consequently, it is possible to write forward-compatible instances
that are valid under this proposal starting with GHC 7.10/`base-4.8`.

Heuristically `grep`ing through Hackage source-code reveals a
non-negligible number of packages defining `Monad` instances with
explicit `return` definitions[4]. This has a comparable impact to the
AMP, and similarly will require a transition scheme aided by compiler
warnings.

### Module Import/Export Specifications

A second source of incompatibility may be due to
`import`s. Specifically module import that assert `return` to be a
method of `Monad`, e.g.:

    import Control.Monad  (Monad ((>>=), return))

or

    import Prelude hiding (Monad(..))
    import Control.Monad  (Monad(..)) as Monad

    f = Monad.return ()

The dual situation can occur when re-exporting `return` via module
export specifications.

However, given that `return` is exported by `Prelude` and the examples
above are rather artificial, we don't expect this to be a major source
of breakage in the case of `return`. In fact, a heuristic grep[5] over
Hackage source-code revealed only 21 packages affected.

### Example for writing compatible code


    instance Functor Foo where
        fmap g foo  = …

    instance Applicative Foo where
        pure x      = …
        a1 <*> a2   = …

    instance Monad Foo where
        m >>= f     = …

    #if !(MIN_VERSION_base(4,8,0))
        return = pure
    #endif


Migration Strategy
------------------

The migration strategy is straightforward:

**Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets
   triggered when `Monad` instances explicitly override the
   default `return` method implementation.

**Phase 2** *(GHC 8.2 or later)*: When we're confident that the
   majority of Hackage has reacted to the warning (with the help of
   Stackage actively pursuing maintainers to update their packages) we
   turn the `return` method into a top-level binding and remove the
   warning implemented in Phase 1 from GHC again.


Discussion period
-----------------

A discussion period of three weeks (until 2015-10-15) should be enough
to allow everyone to chime in as well as leave enough time to make the
required preparations for GHC 8.0 should this proposal pass as we hope.

----

 [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
 [2]: https://wiki.haskell.org/MonadFail_Proposal
 [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
 [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9
 [5]: https://gist.github.com/hvr/afcd040783d980594883
 [6]: https://ghc.haskell.org/trac/ghc/ticket/9590
 [7]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

--

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



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

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

Malcolm Wallace-2
In reply to this post by Henrik Nilsson-2
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
> [hidden email]

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

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

Malcolm Wallace-2
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
>>> [hidden email]
>>
>

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

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

Michał J Gajda
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ł

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

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

Ivan Perez-2
In reply to this post by Johan Tibell-2
On 03/10/15 09:00, johan.tibell at gmail.com (Johan Tibell) wrote:

> -1 from me as well.
>
> I don't find the proposal convincing.
>
> Cons:
>   * Major breakages to existing code (which needs to be updated), docs (many
> of which can't be updated), and future code (coding with ifdefs is error
> prone).
>
> Pros:
>   * A feeling of cleanliness.
Completely agree.

-1 for us too.

Breaking changes are a major problem for us:

- At Keera Studios we are maintaining a bunch of legacy libraries
internally (some of which we
are releasing back via github), for all platforms.

- Also, GHC's Android backend is currently based on 7.8, and don't have
the manpower to maintain it.

> I think there's an implicit argument being made here, that if we let time
> go towards infinity every breaking change is eventually paid off, no matter
> how small the gain. Time doesn't go to infinity for us. Haskell currently
> has a window of opportunity for being adopted and bringing more functional
> programmers to the world. This window isn't very big, perhaps a couple of
> years to a decade. If we make programming in Haskell annoying by
> continuously breaking anything, people will lose interest in Haskell and
> move on to other languages.
In general, regarding how these changes are being introduced:

Time runs fast for us, and our company sits in this window of
opportunity that Johan mentions.

While we understand that changes are necessary, and that this kind of
change benefits from spread adoption to test the community's response
quickly, the decision process that is currently taking place leads to a
form of continuous releases that breaks libraries very often. This costs
us a time that we simply do not have.

We currently deploy Haskell worldwide. Even if our audience is
relatively small in numbers, it is geographically spread. Frequent
backwards-incompatible changes require huge amounts of testing if we
want to do things right. Testing, in our market, without access to your
client's terminal, is expensive.

We prefer to invest time once, fix legacy code once, test it once and
know it's set and working for 3-5 years at least. We have users who have
been running updates of the same Haskell software for 4 years straight
now, without ever hitting a runtime bug. We see consider that not our
success, but Haskell's. We'd like to keep it that way.

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

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

Marcin Mrotek
Perhaps introducing the change now, but extending the transition
period until the next major breakage would bring the best of both
worlds?

Best regards,
Marcin Mrotek
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Sven Panne-2
In reply to this post by Michał J Gajda
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...

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

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

Greg Weber
Does anyone here use base-compat? It has worked quite well in my very limited usage. I think that if the libraries committee officially maintained it then most of the complaints about the difficulties of maintaining backwards-compatible code and having to use conditional compilation would go away. So we have a solution for a large subset of the complaints here, why is nobody using it?

On Mon, Oct 5, 2015 at 6:27 AM, Sven Panne <[hidden email]> 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...

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



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

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

Erik Hesselink
We use base-compat, and it works for addition of functions and
instances. It doesn't work for type class changes like this one.

On 5 October 2015 at 15:46, Greg Weber <[hidden email]> wrote:

> Does anyone here use base-compat? It has worked quite well in my very
> limited usage. I think that if the libraries committee officially maintained
> it then most of the complaints about the difficulties of maintaining
> backwards-compatible code and having to use conditional compilation would go
> away. So we have a solution for a large subset of the complaints here, why
> is nobody using it?
>
> On Mon, Oct 5, 2015 at 6:27 AM, Sven Panne <[hidden email]> 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...
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Gershom Bazerman
In reply to this post by Michał J Gajda
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Language Change Management (was: [Haskell-cafe] 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel-3
In reply to this post by Erik Hesselink
On 2015-10-05 at 15:57:39 +0200, Erik Hesselink wrote:
>> Does anyone here use base-compat? It has worked quite well in my very
>> limited usage. I think that if the libraries committee officially maintained
>> it then most of the complaints about the difficulties of maintaining
>> backwards-compatible code and having to use conditional compilation would go
>> away. So we have a solution for a large subset of the complaints here, why
>> is nobody using it?

> We use base-compat, and it works for addition of functions and
> instances. It doesn't work for type class changes like this one.

Btw, this is exactly why GHC 7.10 droped support for the `haskell2010`
library package. See also

  https://ghc.haskell.org/ticket/9590

for more details about that (and some ideas how to recover a `haskell2010`
package in future GHC versions albeit with some tradeoffs).

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] 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


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

Re: [Haskell-cafe] 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. :-)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] 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]>

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

Re: [Haskell-cafe] 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...

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

Re: [Haskell-cafe] 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


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