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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Language Change Management

Bardur Arantsson-2
On 10/06/2015 09:18 AM, Bardur Arantsson wrote:
> On 10/06/2015 02:49 AM, wren romano wrote:
[--snip--]
>
> No amount of planning can get around the fact that some people simply
> *don't want any change*.
>

Forgot a little side note: Bundling more changes may seem like a good
idea, but that also carries a risk of a) missing potentially *good*
interactions between proposed changes and b) missing potentially
*bad/fatal* interactions between proposed changes. (Again, because
nobody's actually tried them yet.)

Regards,


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

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Johan Tibell-2
In reply to this post by Johan Tibell-2
(Resending with smaller recipient list to avoid getting stuck in the moderator queue.)

On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> On the libraries I maintain and have a copy of on my computer right now: 329


Although this was already pointed out to you in a response to a Tweet of
yours, I'd like to expand on this here to clarify:


You say that you stick to the 3-major-ghc-release support-window
convention for your libraries. This is good, because then you don't need
any CPP at all! Here's why:

[...]

So what do I have to write today to have my Monad instances be:

 * Warning free - Warnings are useful. Turning them off or having spurious warnings both contribute to bugs.
 * Use imports that either are qualified or have explicit import lists - Unqualified imports makes code more likely to break when dependencies add exports.
 * Don't use CPP.

Neither AMP or MRP includes a recipe for this in their proposal. AMP got one post-facto on the Wiki. It turns out that the workaround there didn't work (we tried it in Cabal and it conflicted with one of the above requirements.)

PS: I'm a bit disappointed you seem to dismiss this proposal right away
    categorically without giving us a chance to address your
    concerns. The proposal is not a rigid all-or-nothing thing that
    can't be tweaked and revised.  That's why we're having these
    proposal-discussions in the first place (rather than doing blind
    +1/-1 polls), so we can hear everyone out and try to maximise the
    agreement (even if we will never reach 100% consensus on any
    proposal).

    So please, keep on discussing!

The problem by discussions is that they are done between two groups with quite a difference in experience. On one hand you have people like Bryan, who have considerable contributions to the Haskell ecosystem and much experience in large scale software development (e.g. from Facebook). On the other hand you have people who don't. That's okay. We've all been at the latter group at some point of our career.

What's frustrating is that people don't take a step bad and realize that they might be in the latter group and should perhaps listen to those in the former. This doesn't happen, instead we get lots of "C++ and Java so bad and we don't want to be like them." Haskell is not at risk of becoming C++ or Java (which are a large improvement compared to the languages came before them). We're at risk of missing our window of opportunity. I think that would be a shame, as I think Haskell is a step forward compared to those languages and I would like to see more software that used be written in Haskell.

We've been through this many times before on the libraries list. I'm not going to win an argument on this mailing list. Between maintaining libraries you all use and managing a largish team at Google, I don't have much time for a discussion which approaches a hundred emails and is won by virtue of having lots of time to write emails.

-- Johan


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

Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Johan Tibell-2
In reply to this post by Sven Panne-2
It might be enough to just add a NOWARN <warning type> pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general.

On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari <[hidden email]> wrote:
Sven Panne <[hidden email]> writes:

> 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...
>
This is a fair point that comes up fairly often. The fact that CPP is
required to silence redundant import warnings is quite unfortunate.
Others languages have better stories in this area. One example is Rust,
which has a quite flexible `#[allow(...)]` pragma which can be used to
acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might
introduce a similar idea for import redundancy checks in Haskell,

 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,

        -- in Control.Applicative
        {-# ALLOW redundant_import (<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    asking the compiler to pretend that any import of the symbol did not
    exist when looking for redundant imports. This would allow library
    authors to appropriately mark definitions when they are moved,
    saving downstream users from having to make any change whatsoever.

 2. Or alternatively we could make this a idea a bit more precise,

        -- in Control.Applicative
        {-# ALLOW redundant_import Prelude.(<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    Which would ignore imports of `Control.Applicative.(<$>)` only if
    `Prelude.(<$>)` were also in scope.

 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,

        import {-# ALLOW redundant_import #-} Control.Applicative

        -- or perhaps
        import Control.Applicative
        {-# ALLOW redundant_import Control.Applicative #-}

    allowing the user to explicitly state that they are aware that this
    import may be redundant.

 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
    import list,

        import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

    allowing the user to explicitly state that they are aware that this
    imported function may be redundant.

In general I'd like to reiterate that many of the comments in this
thread describe genuine sharp edges in our language which have presented
a real cost in developer time during the AMP and and FTP transitions. I
think it is worth thinking of ways to soften these edges; we may be
surprised how easy it is to fix some of them.

- Ben


[1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes

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



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

Re: [Haskell-cafe] Reducing the need for CPP

Kosyrev Serge
In reply to this post by Sven Panne-2
Ben Gamari <[hidden email]> writes:

> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
...
>  2. Or alternatively we could make this a idea a bit more precise,
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
...
>  3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,
>         import {-# ALLOW redundant_import #-} Control.Applicative
...
>  4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
>     import list,
>         import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

What I don't like about this solution is how specific it is -- the gut
instinct that it can't be the last such extension, if we were to start
replacing CPP piecemeal.

And after a while, we'd accomodate a number of such extensions..
and they would keep coming.. until it converges to a trainwreck.

I think that what instead needs to be done, is this:

  1. a concerted effort to summarize *all* uses of CPP in Haskell code
  2. a bit of forward thinking, to include desirables that would be easy
     to get with a more generic solution

Personally, I think that any such effort, approached with generality
that would be truly satisfying, should inevitably converge to an
AST-level mechanism.

..but then I remember how CPP can be used to paper over incompatible
syntax changes..

Hmm..

--
с уважениeм / respectfully,
Косырев Серёга
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

Henrik Nilsson-2
In reply to this post by Johan Tibell-2
Dear all,

Executive Summary: Please let us defer further discussion
and ultimate decision on MRP to the resurrected HaskellPrime
committee

While we can discuss the extent of additional breakage
MRP would cause, the fact remains it is a further
breaking change. A survey of breakage to books as
Herbert did is certainly valuable  (thanks!), but
much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last
couple of weeks, on the Haskell libraries list as well
as various other forums and social media, that MRP is
highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge,
the libraries list and its voting process was originally
set up for 3rd-party libraries in fptools. It seems to
have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no
obvious alternative as HaskellPrime has been defunct
for a fair few years. But, as has been pointed out in a
number of postings, a lot of people with very valuable
perspectives are also very busy, and thus likely to
miss a short discussion period (as has happened in the
past in relation to the Burning the Bridges proposal)
and also have very little time for engaging in long and
complicated e-mail discussions that, from their
perspective, happen at a completely random point in
time and for which they thus have not had a chance to
set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham
and me by simply because a) we were too busy to notice
and b) we simply didn't think there was a mandate for
such massive overhauls outside of a process like
HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is
being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking
changes like MRP should be discussed, allowing as much
time as is necessary and allowing for an as wide range
of perspectives as possible to properly be taken into
account?

The need to "field test" MRP prior to discussing
it in HaskellPrime has been mentioned. Graham and I
are very sceptical. In the past, at least in the
past leading up to Haskell 2010 or so, the community
at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of
HaskellPrime being imminent, Graham and I strongly believe
that risks coming across to a very large part of the
Haskell community as preempting proper process by facing
the new HaskellPrime committee with (yet another) fait
accompli.

Therefore, please let us defer further discussion and
ultimate decision on MRP to the resurrected
HaskellPrime committee, which is where it properly
belongs. Otherwise, the Haskell community itself might
be one of the things that MRP breaks.

Best regards,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

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

Augustsson, Lennart
To question 1 my answer is NO!  I think voting to decide these kind of issues a terrible idea; we might as well throw dice.

-----Original Message-----
From: Haskell-Cafe [mailto:[hidden email]] On Behalf Of Henrik Nilsson
Sent: 06 October 2015 12:33
To: [hidden email] List; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Dear all,

Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee

While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable  (thanks!), but much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account?

The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli.

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

Best regards,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Jan-Willem Maessen
In reply to this post by Sven Panne-2


On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari <[hidden email]> wrote:
Sven Panne <[hidden email]> writes:

> 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...
>
This is a fair point that comes up fairly often. The fact that CPP is
required to silence redundant import warnings is quite unfortunate.
Others languages have better stories in this area. One example is Rust,
which has a quite flexible `#[allow(...)]` pragma which can be used to
acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might
introduce a similar idea for import redundancy checks in Haskell,

 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,

        -- in Control.Applicative
        {-# ALLOW redundant_import (<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    asking the compiler to pretend that any import of the symbol did not
    exist when looking for redundant imports. This would allow library
    authors to appropriately mark definitions when they are moved,
    saving downstream users from having to make any change whatsoever.

 2. Or alternatively we could make this a idea a bit more precise,

        -- in Control.Applicative
        {-# ALLOW redundant_import Prelude.(<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    Which would ignore imports of `Control.Applicative.(<$>)` only if
    `Prelude.(<$>)` were also in scope.

One obvious solution I haven't seen mentioned is the ability to add nonexistent identifier to a hiding clause (these identifiers might presumably exist in some other version of the import):

import Prelude hiding ((<$>))

I can see the argument for marking such imports with a pragma, though it gets a bit ugly.

-Jan-Willem Maessen

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
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
In reply to this post by Henrik Nilsson-2
On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.

I'd like to point out, that the core libraries committee ought to
continue to do so (as hinted at in [1]) in its function as a Haskell
Prime sub-Committee (c.f. sub-teams in the Rust community[2]).

While there will be surely overlap of interests, contributions,
cross-reviewing and discussion, the principal task and responsibility of
the new sought members is to concentrate on the language part of the
Haskell Report where quite a bit of work is awaiting them.

Cheers,
  hvr

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://www.rust-lang.org/team.html
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Bardur Arantsson-2
In reply to this post by Johan Tibell-2
On 10/06/2015 10:12 AM, Johan Tibell wrote:

> (Resending with smaller recipient list to avoid getting stuck in the
> moderator queue.)
>
> On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <[hidden email]> wrote:
>
>> PS: I'm a bit disappointed you seem to dismiss this proposal right away
>>     categorically without giving us a chance to address your
>>     concerns. The proposal is not a rigid all-or-nothing thing that
>>     can't be tweaked and revised.  That's why we're having these
>>     proposal-discussions in the first place (rather than doing blind
>>     +1/-1 polls), so we can hear everyone out and try to maximise the
>>     agreement (even if we will never reach 100% consensus on any
>>     proposal).
>>
>>     So please, keep on discussing!
>>
>
> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
>

Given that Facebook's motto is "move fast and break things", I'm not
sure what to make of this appeal to authority.

Ignoring the condescension...

> What's frustrating is that people don't take a step bad and realize that
> they might be in the latter group and should perhaps listen to those in the
> former.

Have you considered that people might actually have done that and just
come to a different conclusion from yours?

Have you also considered that people *you've* put in the latter group
might actually be in the former in terms of general experience on large
language ecosystems/projects/etc.?

(Certainly contributing to the Haskell ecosystem does signify a certain
level of understanding/insight and shouldn't be *discounted*, but nor
should it be used to just outright discount the opinions of others
without good reason.)

> This doesn't happen, instead we get lots of "C++ and Java so bad
> and we don't want to be like them." Haskell is not at risk of becoming C++
> or Java (which are a large improvement compared to the languages came
> before them). We're at risk of missing our window of opportunity. I think
> that would be a shame, as I think Haskell is a step forward compared to
> those languages and I would like to see more software that used be written
> in Haskell.

If Haskell is not appealing enough to overcome these obstacles, then
it's not very appealing, period. That is: if *this* is the deciding
factor, then perhaps one *shouldn't* be using Haskell. (That would be a
perfectly legitimate business decision.)

>
> We've been through this many times before on the libraries list. I'm not
> going to win an argument on this mailing list. Between maintaining
> libraries you all use and managing a largish team at Google, I don't have
> much time for a discussion which approaches a hundred emails and is won by
> virtue of having lots of time to write emails.
>

I'm sure nobody other than you has any drains on their time outside of
posting to this list.

(And no, if you're going to argue like you did in this post, then you
*aren't* going to win any arguments. That's pretty much a
self-fulfilling prophesy.)

Regards,

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

Re: Reducing the need for CPP

Bardur Arantsson-2
In reply to this post by Johan Tibell-2
On 10/06/2015 11:11 AM, Johan Tibell wrote:
> It might be enough to just add a NOWARN <warning type> pragma that acts on
> a single line/expression. I've seen it in both C++ and Python linters and
> it works reasonably well and it's quite general.

+1. Simple is good and can hopefully also be backported to older GHC
releases. (Provided someone's willing to do said releases, obviously.)


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

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Herbert Valerio Riedel
In reply to this post by Herbert Valerio Riedel
On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote:
[...]

>> You say that you stick to the 3-major-ghc-release support-window
>> convention for your libraries. This is good, because then you don't need
>> any CPP at all! Here's why:
>>
>> [...]
>>
>
> So what do I have to write today to have my Monad instances be:
>
>  * Warning free - Warnings are useful. Turning them off or having spurious
> warnings both contribute to bugs.

Depends on the warnings. Some warnings are more of an advisory kind
(hlint-ish). I wouldn't consider redundant imports a source of
bugs. Leaving off a top-level signature shouldn't be a source of
correctness bugs either. Also, warnings about upcoming changes
(i.e. deprecation warnings) also are not necessarily a bug, but rather a
way to raise awareness of API changes.

At the other end of the spectrum are more serious warnings I'd almost
consider errors, such as failing to define a non-defaulting method or
violating a MINIMAL pragma specification, as that can lead to bottoms
either in the form of runtime errors or even worse, hanging computations
(in case of cyclic definitions).

IMO, GHC should classify its warnings into severities/categories or
introduce some compromise between -Wall and not-Wall.

>  * Use imports that either are qualified or have explicit import lists -
> Unqualified imports makes code more likely to break when dependencies add
> exports.
>  * Don't use CPP.

That being said, as how to write your Monad instances today with GHC
7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
*does* work (admittedly for an easy example, but this can be
generalised):


--8<---------------cut here---------------start------------->8---
module MyMaybe where

import Control.Applicative (Applicative(..))
import Prelude (Functor(..), Monad(..), (.))
-- or alternatively: `import qualified Prelude as P`

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10

--8<---------------cut here---------------end--------------->8---

This example above compiles -Wall-clean and satisfies all your 3 stated
requirements afaics. I do admit this probably not what you had in mind.

But to be consistent, if you want to avoid unqualified imports at all
costs in order to have full control of what gets imported into your
namespace, you shouldn't tolerate an implicit unqualified wildcard
`Prelude` import either. As `Prelude` can, even if seldom, gain new
exports as well (or even loose them -- `interact` *could* be a candidate
for removal at some point).


> Neither AMP or MRP includes a recipe for this in their proposal.

That's because -Wall-hygiene (w/o opting out of harmless) warnings
across multiple GHC versions is not considered a show-stopper.

In the specific case of MRP, I can offer you a Wall-perfect transition
scheme by either using `ghc-options: -fno-mrp-warnings` in your
cabal-file, or if that doesn't satisfy you, we can delay phase1
(i.e. redundant return-def warnings) to GHC 8.2:

Now you can continue to write `return = pure` w/o GHC warning bothering
you until GHC 8.2, at which point the 3-year-window will reach to GHC
7.10.

Then starting with GHC 8.2 you can drop the `return` definition, and
keep your


More generally though, we need more language-features and/or
modifications to the way GHC triggers warnings to make such
refactorings/changes to the libraries -Wall-perfect as well.

Beyond what Ben already suggested in another post, there was also the
more general suggestion to implicitly suppress warnings when you
explicitly name an import. E.g.

  import Control.Applicative (Applicative(..))
 
would suppress the redundant-import warning for Applicative via Prelude,
because we specifically requested Applicative, so we don't mind that
Prelude re-exports the same symbol.


> AMP got one post-facto on the Wiki. It turns out that the workaround
> there didn't work (we tried it in Cabal and it conflicted with one of
> the above requirements.)

Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki
breaks down for more complex imports with (redundant) explicit import
lists.

However, the Maybe-example above works at the cost of a wordy
Prelude-import, but it's more robust, as you pin down exactly which
symbol you expect to get from each module.



> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
[...]

At the risk of stating the obvious: I don't think it matters from which
group a given argument comes from as its validity doesn't depend on the
messenger. Neither does it matter whether an argument is repeated
several times or stated only once. Also, every argument deserves to be
considered regardless of its origin or frequency.


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

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Herbert Valerio Riedel

I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?

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

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Herbert Valerio Riedel
In reply to this post by Herbert Valerio Riedel

I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?

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

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Sven Panne-2
In reply to this post by Herbert Valerio Riedel
2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
[...] That being said, as how to write your Monad instances today with GHC
7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
*does* work (admittedly for an easy example, but this can be
generalised):


--8<---------------cut here---------------start------------->8---
module MyMaybe where

import Control.Applicative (Applicative(..))
import Prelude (Functor(..), Monad(..), (.))
-- or alternatively: `import qualified Prelude as P`
[...]
--8<---------------cut here---------------end--------------->8---

This example above compiles -Wall-clean and satisfies all your 3 stated
requirements afaics. I do admit this probably not what you had in mind.

OK, so the trick is that you're effectively hiding Applicative from the Prelude (which might be a no-op). This "works" somehow, but is not satisfactory IMHO for several reasons:

   * If you explicitly import all entities from Prelude, your import list will typically get *very* long and unreadable. Furthermore, if that's the suggested technique, what's the point of having a Prelude at all?

   * Some people see qualified imports as the holy grail, but having to prefix tons of things with "P." is IMHO very ugly. Things are even worse for operators: The whole notion of operators in itself is totally useless and superfluous *except* for a single reason: Readability. And exactly that gets destroyed when you have to qualify them, so I would (sadly) prefer some #ifdef hell, if that gives me readable code elsewhere.

   * With the current trend of moving things to the Prelude, I can envision a not-so-distant future where the whole Control.Applicative module will be deprecated. As it is now, it's mostly superfluous and/or contains only stuff which might better live somewhere else.
 
[...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
across multiple GHC versions is not considered a show-stopper.

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one.
 
[...] Beyond what Ben already suggested in another post, there was also the
more general suggestion to implicitly suppress warnings when you
explicitly name an import. E.g.

  import Control.Applicative (Applicative(..))

would suppress the redundant-import warning for Applicative via Prelude,
because we specifically requested Applicative, so we don't mind that
Prelude re-exports the same symbol. [...]

Uh, oh... That would be bad, because one normally wants to see redundant imports. Without the compiler telling me, how should I find out which are redundant? Manually trying to remove them step by step? :-/

Cheers,
   S.

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

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Malcolm Wallace-2
In reply to this post by Herbert Valerio Riedel

On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:

>
>> The problem by discussions is that they are done between two groups with
>> quite a difference in experience. On one hand you have people like Bryan,
>> who have considerable contributions to the Haskell ecosystem and much
>> experience in large scale software development (e.g. from Facebook). On the
>> other hand you have people who don't. That's okay. We've all been at the
>> latter group at some point of our career.
> [...]
>
> At the risk of stating the obvious: I don't think it matters from which
> group a given argument comes from as its validity doesn't depend on the
> messenger.

In that case, I think you are misunderstanding the relevance of Johan's argument here.  Let me try to phrase it differently.  Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be.  On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases.  The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact.

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

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Herbert Valerio Riedel
In reply to this post by Herbert Valerio Riedel
Hi,

On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote:
> On 6 October 2015 at 19:03, Herbert Valerio Riedel <[hidden email]> wrote:
>>> In the specific case of MRP, I can offer you a Wall-perfect transition
>>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>>> cabal-file, [...]
>
> Apropos, is there a similar option for AMP warnings? I would rather
> use that than CPP.

Sure, added in GHC 7.8:

| In GHC 7.10, Applicative will become a superclass of Monad,
| potentially breaking a lot of user code. To ease this transition, GHC
| now generates warnings when definitions conflict with the
| Applicative-Monad Proposal (AMP).
|
| A warning is emitted if a type is an instance of Monad but not of
| Applicative, MonadPlus but not Alternative, and when a local function
| named join, <*> or pure is defined.
|
| The warnings are enabled by default, and can be controlled using the
| new flag -f[no-]warn-amp.


However, if you use that now with GHC 7.10 you get a warning:

| $ ghc-7.10.2 -fno-warn-amp
|  
| on the commandline: Warning:
|     -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12

so you you'll need to guard that with something like

  if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp

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

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

José Manuel Calderón Trilla
In reply to this post by Sven Panne-2
Hello all,

I agree with Henrik, I'm very keen on giving the new Haskell committee a shot.

While some may not think that Haskell2010 was a success, I think it would be difficult to argue that Haskell98 was anything but a resounding success (even if you don't think the language was what it could have been!). Haskell98 stabilized the constant changes of the proceeding 7 years. The stability brought with it books and courses, and the agreed-upon base of the language allowed _research_ to flourish as well. Having an agreed base allowed the multiple implementations to experiment with different methods of implementing what the standard laid out.

Many of us here learned from those texts or those courses. It's easy online to say that materials being out of date isn't a big deal, but it can turn people off the language when the code they paste into ghci doesn't work. We use Haskell for the compilers course at York; Haskell is the means, not the end, so having to update the materials frequently is a significant cost. It can be difficult to defend the choice of using Haskell when so much time is spent on something that 'isn't the point' of the course.

Does that mean that we should never change the language? Of course not, but this constant flux within Haskell is very frustrating. Maybe Haskell2010 wasn't what everyone wanted it to be, but that does not mean the _idea_ of a committee is without merit. Having controlled, periodic changes that are grouped together and thought through as a coherent whole is a very useful thing. One of the insights of the original committee was that there would always be one chair at any point in time. The chair of the committee had final say on any issue. This helped keep the revisions coherent and ensured that Haskell made sense as a whole.

Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago when the issue of incompatible changes
came up. His thoughts were similar to Johan's:

On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote:
> As a practical suggestion, if any changes for version 1.3 could make
> some revision of a 1.2 programs necessary, let's have a precise
> stand-alone specification of these revisions and how to make them.
> It had better be short and simple.  Many would prefer it to be empty.
> Perhaps it should be implemented in Haskell compilers?


Overall I don't see the rush for these changes, let's try putting our faith in a new Haskell committee, whomever it is comprised of.

Best wishes,

José Manuel

P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I was studying his thesis. I was able to run the code without issue, allowing me to be more productive in my research ;-)

On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins <[hidden email]> wrote:

On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <[hidden email]> wrote:
In fact I think all of these apart from the FFI one could be solved with a
-compat package, could they not?

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

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

--
Gregory Collins <[hidden email]>

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



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

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Gershom Bazerman
In reply to this post by Herbert Valerio Riedel
Dear all,

I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact.

Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled). 

I. Generalities

That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases.

I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world’s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I’m sure it will be taken into account in future proposals as well.

I don’t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print “hello world” to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat “improvement” versus “stability” as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity.

II. Particulars

With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins’ list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don’t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated.

Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee). 

Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years — particularly but not only regarding its handling of doubles. I don’t begrudge these changes — they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of “die” to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and “real” users with “real” code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say “base never changes” that does not mean “packages will never break” — it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP.

III. Discussions

Further, since there has been much discussion of a window of opportunity, I would like to offer a counterpoint to the (sound) advice that we take into consideration voices with long experience in Haskell. The window of opportunity is, by definition, regarding takeup of Haskell by new users. And so if newer users favor certain changes, then it is good evidence that those changes will help with uptake among other new users. So, if they are good changes on their own, then the fact that they are appealing to newer users should be seen as a point in their favor, rather than a reason to dismiss those opinions. But if we are in a situation where we see generations of adopters pitted against one another, then we already have deeper problems that need to be sorted out.

Regarding where and how to have these discussions — the decision was made some time ago (I believe at the start of the initial Haskell Prime process if not sooner, so circa 2009?) that the prime committee would focus on language extensions and not library changes, and that those changes would be delegated to the libraries@ list. The lack of structure to the libraries@ list is what prompted the creation of the libraries committee, whose ultimately responsibility it is to decide on and shepherd through these changes, in consultation with others and ideally driven by broad consensus. Prior to this structure, things broke even more, imho, and simultaneously the things that were widely desired were still not implemented. So I thank the libraries committee for their good work so far.

So, it may be that the process of community discussion on core libraries changes is not best suited for the libraries@ list. But if not there, Where? I worry that the proliferation of lists will not improve things here. Those involved with Haskell have multiplied (this is good). The voices to take into account have multiplied (this is good). Necessarily, this means that there will just be _more_ stuff, and making sure that everyone can filter to just that part they want to is difficult. Here, perhaps, occasional libraries-related summary addenda to the ghc newsletter could be appropriate? Or is there another venue we should look towards? “Chair’s reports” to the Haskell Weekly News maybe?

IV. Summing up

We should bear in mind after all that this is just about cleaning up a redundant typeclass method (albeit one in a very prominent place) and hardly the hill anyone would want to die on [4]. Nonetheless, I think it would be a good sign of progress and collaboration if we can find a way to implement a modest change like this in a way that everyone finds acceptable vis a vis a sufficiently slow pace, the lack of a need for CPP and the lack of any induced warnings. On the other hand, other opportunities will doubtless present themselves in the future.

Best,
Gershom

[1] https://mail.haskell.org/pipermail/libraries/2015-February/025009.html
[2] https://wiki.haskell.org/Library_submissions#The_Core_Libraries
[3] and in any case I am sure Bryan would be the last to want us to treat him as some sort of “guru” on these matters. 
[4] for those in search of better hills to die on, this is a list of some good ones: http://www.theawl.com/2015/07/hills-to-die-on-ranked 

P.S. In case there is any question, this email, as all emails I write that do not state otherwise, is not being written in any particular capacity regarding the various infra-related hats I wear, but is just an expression of my own personal views.


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

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Herbert Valerio Riedel
In reply to this post by Sven Panne-2
On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote:

> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
>
>> [...] That being said, as how to write your Monad instances today with GHC
>> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
>> *does* work (admittedly for an easy example, but this can be
>> generalised):
>>
>>
>> --8<---------------cut here---------------start------------->8---
>> module MyMaybe where
>>
>> import Control.Applicative (Applicative(..))
>> import Prelude (Functor(..), Monad(..), (.))
>> -- or alternatively: `import qualified Prelude as P`
>> [...]
>> --8<---------------cut here---------------end--------------->8---
>>
>> This example above compiles -Wall-clean and satisfies all your 3 stated
>> requirements afaics. I do admit this probably not what you had in mind.
>>
>
> OK, so the trick is that you're effectively hiding Applicative from the
> Prelude (which might be a no-op). This "works" somehow, but is not
> satisfactory IMHO for several reasons:

[...]

Btw, I've also seen the trick below, in which you use the aliased `A.`
prefix just once so GHC considers the import non-redundant, and don't
have to suffer from prefixed operators in the style of `A.<*>`.

Is this any better?

--8<---------------cut here---------------start------------->8---
import Control.Applicative as A (Applicative(..))

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance A.Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10
--8<---------------cut here---------------end--------------->8---

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

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Sven Panne-2
2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
Btw, I've also seen the trick below, in which you use the aliased `A.`
prefix just once so GHC considers the import non-redundant, and don't
have to suffer from prefixed operators in the style of `A.<*>`.

Is this any better? [...]

While not perfect, it's much better than having to fiddle around with Prelude imports. Although there's the slight danger that somebody else (or the author 1 year later) looks at the code and has a WTF-moment... ;-) To be honest, while it's somehow obvious how it works when you read it, I've never seen that trick. Perhaps stuff like this belongs into some general "Porting Guide", along with its alternatives. It's general enough that it should not be buried in some AMP/FTP/return/... transitioning guide.

Cheers,
   S.

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