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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
243 messages Options
1 ... 567891011 ... 13
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`)

Mark Lentczner-2

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <[hidden email]> wrote:
TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

Think of it as Perl 6 or Python 3 for Haskell.

- Mark

On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell <[hidden email]> 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:
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


_______________________________________________
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`

Gregory Collins-3
In reply to this post by Tom Ellis

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



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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`)

Mike Meyer
In reply to this post by Mark Lentczner-2
On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <[hidden email]> wrote:

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <[hidden email]> wrote:
TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind?

#2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?

_______________________________________________
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`

Phil Ruffwind
In reply to this post by John Wiegley-2
> By comparison, the C++ language -- significantly more complex and affecting a
> much larger community of users -- has released 4 separate standards in the
> timeframe between Haskell 98 and now, each of them introducing significant
> functionality that created work for compiler and tools vendors, users,
> authors, teachers, and learners. If they can do it, I'm confident we can as
> well.

C++ never makes any breaking changes.* It has only added things (with
the undesirable effect of making the newer and more useful things more
verbose than the legacy cruft).

[*]: … minus a few rare cases where the features had 0% usage, like
'export templates', so their removal wasn't at all controversial.
_______________________________________________
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] 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.


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

Haskell ecosystem improvements meta-propsal

Mike Meyer
There's been a lot of complaints about the way things have worked in the past, with things going to fast, or to slow, or the right people not being heard, or notices not going to the right places, etc.

As far as I can tell, the current process is that someone make a proposal on some mailing list, that gets debated by those who find out about it, maybe a wiki page gets set up and announced to those who already know about the proposal, and then it either happens or not.

There's actually quite a bit of experience with dealing with such. I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that. So I think we can do better.

I'd like to suggest we adapt something a bit more formal that any process that changes a developer-visible API should have to go through. Note that bug fixes, most security fixes, and other things that don't change the API wouldn't be subject to this requirement. However, any change in an API, even one that's 100% backward compatible, not possibly breaking any code, would be. Initial thoughts on scope are anything in the Haskell Platform, as that seems to be a minimal definition of "Haskell ecosystem". Further, anything on hackage should be able to avail itself of the process.

My concrete, though very broad proposal, with lots of details to be filled in yet, is that we need:

1) A wiki page that lists all proposals being considered, along with their current status and other relevant information.

2) A set of requirements a proposal must meet in order to be listed on that page.

3) An announcements list that only has announcements of things being added to the list. Anybody who has time to vote on a proposal should have time to be on this list.

4) An editorial group responsible for maintaining the list and providing guidance on meeting the requirements to get on it.

The first three are easy. The fourth one is the killer. Somebody to do the work is the stumbling block for most proposals. This doesn't require deep technical knowledge of Haskell or the current ecosystem, but the ability to implement a process and judge things based on form and not content, Since it's my proposal, I'll volunteer as the first editor. Hopefully, others with better reputation will alsob e available.

If adopted, the first two things on the list need to be a description of the process, followed shortly by a description of the requirements to be met.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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`)

Mark Lentczner-2
In reply to this post by Mike Meyer
Mike -

You might look up the phrase "A modest proposal".

... for gnus sake let's not adopt the inane parity implies stability numbering convention ...

6.10 .. 6.12 .. 7.0 .. 7.2 .. 7.4 .. 7.8 .. 7.10

- Mark 

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

Re: Haskell ecosystem improvements meta-propsal

Mark Lentczner-2
In reply to this post by Mike Meyer

On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <[hidden email]> wrote:
I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that.

While both those are good examples of mostly working organizations shepherding foundational technical standard(s) along... there is one thing more important than their processes: Their stance. Both organizations have a very strong engineering discipline of keeping deployed things working without change. I don't think it is enough to simply model their process.

Until about three years ago, the Haskell community also had such a discipline. It has been steadily eroding over the last few years.

- Mark



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

Re: Haskell ecosystem improvements meta-propsal

Mike Meyer
On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <[hidden email]> wrote:
On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <[hidden email]> wrote:
I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that.

While both those are good examples of mostly working organizations shepherding foundational technical standard(s) along... there is one thing more important than their processes: Their stance. Both organizations have a very strong engineering discipline of keeping deployed things working without change. I don't think it is enough to simply model their process.

Well, until Python 3, anyway.

My goal wasn't to recreate the engineering discipline that deployed things keep working without change as you upgrade the ecosystem, it's to provide a mechanism so the community can more easily engage with the evolution of the ecosystem. Hopefully this will make it easier for the community to move things forward in a desirable manner. But it's a process, and leaves the question of whether the desire is for more stability or a less stagnant language up to the users of the process.

I don't necessarily want to model the IETF or PEP processes. Those are a starting point. I tried to abstract the initial points out enough that the final result could be either one of them, or something totally unrelated that's a better fit for the Haskell community.

_______________________________________________
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] 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  
_______________________________________________
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] 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.

_______________________________________________
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`

Malcolm Wallace-2
In reply to this post by John Wiegley-2

On 6 Oct 2015, at 19:31, John Wiegley wrote:

> It must be stated, however, that some have
> become frustrated by the frozen state the Haskell language has entered. No
> substantial changes have occurred since 1998.

Haskell has de-facto undergone huge changes and additions since 1998.  The official language standard may not have kept pace, but a huge amount has happened in the last 17 years:  FFI, Cabal&Hackage, type families, just to pick the first three that come to mind.

No-one objects to these improvements.  The language and its ecosystem are not frozen.  What many people do object to is unnecessary and under-motivated breakage of existing code.  The "monad of no return" proposal promises no new semantic benefits, just a small conceptual tidy-up, but at a huge cost to the community at large.  It is of a completely different category to the substantial and useful changes that we are used to.

Regards,
   Malcolm
_______________________________________________
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] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Simon Peyton Jones
In reply to this post by Mike Meyer

I think there are several different conversations going on at once in this thread.  I think it’s worth keeping them separate.

 

·         Haskell Prime.  The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report.   That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round.

 

I think it’d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested.

·         Libraries.  AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries.  I think there was a consensus (not universal in the case of BBP) that the change was good.  Yet AMP and BBP (esp) were controversial.  The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change.  The question of moving ‘return’ out of Monad is in this category.

The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime.

 

Mark’s suggestion of a “stable” GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). 

 

Here is another idea.  GHC knows very little about Monad.  It would take work, but it probably wouldn’t be impossible to make the same GHC work with two different ‘base’ libraries, each with a different definitions of the Monad class.  That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad.   But at least it’d decouple it from which version of GHC you were using.  I stress: it would take some work to make this go, and I’d prefer not to do this.

 

Returning to ‘return’, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps.  The “treadmill” complaint is real: small change A made me re-release my library; then small change B came along; and so on.  Perhaps if we saved them up this would be less of an issue, for two reasons.  First, the work happens once rather than many times.  Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients.

 

That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being “saved up” for execution at some later date.

 

Simon

 

 

From: Haskell-Cafe [mailto:[hidden email]] On Behalf Of Mike Meyer
Sent: 07 October 2015 00:24
To: Mark Lentczner; Johan Tibell
Cc: Haskell Libraries; haskell cafe; [hidden email] List
Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

 

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <[hidden email]> wrote:


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

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

 

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

 

A modest proposal:

 

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

 

I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit.

 

While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed.

 

#1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind?

 

#2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?


_______________________________________________
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] MRP, 3-year-support-window, and the non-requirement of CPP

Gregory Collins-3
In reply to this post by Gershom Bazerman
On Tue, Oct 6, 2015 at 6:18 PM, Gershom B <[hidden email]> wrote:
 

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 fact, more often than I would like, I can recall arguing against a particular change on the grounds that it would break user code, and in Haskell land this is a battle I usually lose. Usually the argument on the other side boils down to expediency or hygiene/aesthetics -- it's difficult to engineer a change to some core infra in a way that minimizes impact on people downstream, and it takes a long time. Often "this change is going to cause a small amount of work for all of my users" is something that seems to not be taken into consideration at all.

For this particular proposal, every user will have some small amount of work w to do (to read the change notes, understand why 'return' is going away, train yourself to use "pure" now instead of "return" like you've been using for 15 years, etc). It might feel like w is small and so the change isn't burdensome, but n is literally everyone who uses the language, so the total work w*n is going to amount to quite a few person-hours. I just want to make sure that everyone is keeping that in mind and weighing that effort against the benefits.

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.

Culturally, we have a problem with library authors of all stripes being too cavalier about breaking user programs: we definitely lean towards "move fast and break things" vs "stay stable and don't make work for users". As you write more and more Haskell code, you depend on more and more of these libraries, and this means that once you go beyond a certain threshold you will be spending a significant amount of your time just running to keep up with the treadmill. Personally I just don't have enough time for writing Haskell code as I used to (or I would like), so I would say for me that the treadmill tax is now probably exceeding 50% of my total hours invested.

Greg

_______________________________________________
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] MRP, 3-year-support-window, and the non-requirement of CPP

Erik Hesselink
On 7 October 2015 at 18:09, Gregory Collins <[hidden email]> wrote:
> For this particular proposal, every user will have some small amount of work
> w to do (to read the change notes, understand why 'return' is going away,
> train yourself to use "pure" now instead of "return" like you've been using
> for 15 years, etc).

While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Erik
_______________________________________________
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] MRP, 3-year-support-window, and the non-requirement of CPP

Mark Lentczner-2

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <[hidden email]> wrote:
While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Then why bother?
If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc....
If you don't intend to correct people on #haskell to use pure instead of return...
If you don't tsk tsk all mentions of it in books.... 
If you don't intend to actually deprecate it.
Why bother?

But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones.

Why bother!


_______________________________________________
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] MRP, 3-year-support-window, and the non-requirement of CPP

Manuel Gómez
On Wed, Oct 7, 2015 at 4:43 PM, Mark Lentczner <[hidden email]> wrote:

> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has a
> library that defines a Monad - or anyone who has a library that they want to
> keep "up to date". Do you really want to have a library where all your "how
> to use this" code has return in the examples? Shouldn't now be pure? Do I
> now need -XCPP just for Haddock? and my wiki page? And what gets shown in
> Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!

This is explained in the original proposal.  In particular, it
eliminates opportunities for errors and simplifies ApplicativeDo.  I
don’t believe anyone has proposed removing return from base.  The only
proposed change is turning return into a stand-alone function instead
of a method in Monad.  There is no proposal for removing return.
_______________________________________________
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`

Brandon Allbery
In reply to this post by José Manuel Calderón Trilla

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <[hidden email]> wrote:
Please consider that the the way practical development really happens[2]

...among web developers, who of course are the only real developers?

Have you considered that there are developers who are not web developers?
The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers.

I had heard that the financial users generally refused to have anything to do with the Haskell community.
Now I know why.

I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers".

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.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`

Mike Meyer
On Wed, Oct 7, 2015 at 6:05 PM Brandon Allbery <[hidden email]> wrote:
On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <[hidden email]> wrote:
Please consider that the the way practical development really happens[2]
...among web developers, who of course are the only real developers?
[...]
I had heard that the financial users generally refused to have anything to do with the Haskell community.
Now I know why.

I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort.

So the worst headache I got from language evolution was from trying to remember which set of features I had available for each project. No, that's second - the biggest one was from arguments about when we should adopt a new version. But breaking working code pretty much didn't happen.

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