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 ... 678910111213
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
On 10/08/2015 01:39 AM, Mike Meyer wrote:

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

+1, that's an excellent point well made.

I have been in this situation and it was certainly frustrating *as a
developer*, but it pretty much works for most businesses.

Regards,

_______________________________________________
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

Edward Kmett-2
In reply to this post by Malcolm Wallace-2


On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace <[hidden email]> wrote:

On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
> 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.

Very well. Let me offer a view from the "other side of the fence."

I personally maintain about 1.3 million lines of Haskell, and over 120 packages on hackage. It took me less than a half a day to get everything running with 7.10, and about two days to build -Wall clean. In that first day I actually had to spend vastly more time fixing things related to changes in Typeable, template-haskell and a tweaked corner case in the typechecker than anything AMP/FTP related. In the end I had to add two type signatures.

Most of the patches to go -Wall clean looked like

+#if __GLASGOW_HASKELL__ < 710
import Control.Applicative
import Data.Monoid
+#endif

Maybe 10% were more complicated.

-Edward

_______________________________________________
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

Edward Kmett-2
In reply to this post by Herbert Valerio Riedel


On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel <[hidden email]> wrote:
--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---


Alternately,

import Control.Applicative
import Prelude

data Maybe' a = Nothing' | Just' a

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

instance Applicative Maybe' where

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


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

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

Edward Kmett-2
In reply to this post by Mark Lentczner-2
The part of the MRP proposal that I actively care about because it fixes a situation that actually causes harm is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <[hidden email]> wrote:

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



_______________________________________________
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

Edward Kmett-2
In reply to this post by Sven Panne-2
On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne <[hidden email]> wrote:
2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
[...] 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.

Note: You haven't been able to upload a package that has -Werror turned on in the cabal file for a couple of years now -- even if it is only turned on on the test suite, so any -Werror discipline you choose to enforce is purely local.

-Edward

_______________________________________________
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

Yuras Shumovich
In reply to this post by Edward Kmett-2
On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true. But we can leave `return` is `GHC` as a compiler specific
extension for backward compatibility, can't we?

The second argument is `ApplicativeDo`, but I don't see the point.
Breaking existing code "in order to benefit existing code" looks a bit
strange.

Could someone please clarify what is the cost of not moving `return`
out of `Monad`?

Sorry if it is already answered somewhere else, it is hard to find
anything in such the huge email thread.

Thanks,
Yuras.

_______________________________________________
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

Edward Kmett-2
On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <[hidden email]> wrote:
On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out.


In many ways that proposal would do better 'on its own' than as part of the MRP.

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true.

Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line.

But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we?

This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day.

There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect.

Could someone please clarify what is the cost of not moving `return` out of `Monad`?

The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. 

While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. 

I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all.

-Edward

_______________________________________________
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

Yuras Shumovich
On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote:

> On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <
> [hidden email]>
> wrote:
>
> > There is no reason to include `return` into the next standard. That
> > is
> > true.
>
>
> Nobody is saying that we should remove return from the language. The
> proposal was to move it out of the class -- eventually. Potentially
> on a
> very very long time line.

Yes, I meant there were no reason to include `return` into `Monad`
class in the next standard.


> There are some niggling corner cases around viewing its continued
> existence
> as a compiler "extension" though, even just around the behavior when
> you
> import the class with Monad(..) you get more or less than you'd
> expect.

Indeed that is a good argument.


> The cost of doing nothing is maintaining a completely redundant
> member
> inside the class for all time

Well, it is just a single line of code. Of course, as any other
technical dept, it can beat you later, e.g. it can make some other
modification harder. But in the worst case it will cost one more
deprecation circle.


> and an ever-so-slightly more expensive
> dictionaries for Monad

Do you mean that moving `return` to the top level will give us
noticeable performance improvement?


> so retaining return in the class does no real harm
> operationally.

IMO that is the reason for the "ruckus".


Thank you for the detailed answer.

Yuras


>
> While I'm personally somewhat in favor of its eventual migration on
> correctness grounds and believe it'd be nice to be able to justify
> the
> state of the world as more than a series of historical accidents when
> I put
> on my libraries committee hat I have concerns.
>
> I'm inclined to say at the least that IF we do decide to proceed on
> this,
> at least the return component should be on a long time horizon, with
> a
> clock tied to the release of a standard, say a Haskell2020. I stress
> IF,
> because I haven't had a chance to go through and do any sort of
> detailed
> tally or poll to get a sense of if there is a sufficient mandate.
> There is
> enough of a ruckus being raised that it is worth proceeding
> cautiously if
> we proceed at all.
>
> -Edward
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Arrow syntax vs. functional style (Was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Henning Thielemann
In reply to this post by Henrik Nilsson-2

On Sat, 3 Oct 2015, Henrik Nilsson wrote:

> For example, I have written quite a bit of applicative code, way before
> it was even called applicative, and I did not find the lack of syntactic
> support particularly bothersome. On the other hand, I have also written
> a lot of arrowized code, and there, while I do use the syntactic sugar
> to allow me to name certain things, the fact that I then have to name
> everything is rather annoying to say the least, and I have often found
> myself wishing that I could write arrowized code that looked a lot more
> like applicative code (without the sugar).

I was unhappy about arrow syntax for the same reasons and with Mr.
Apfelmus I developed a technique that allows to apply Arrows in an
Applicative style. However, because it relies on the Vault data structure
it works efficiently only for EDSL things. Unfortunately we have not
written up the method so far, I have only a complicated module that
employs the method:
    https://hackage.haskell.org/package/synthesizer-llvm-0.7.0.1/src/src/Synthesizer/LLVM/CausalParameterized/Functional.hs

If I find time I could extract the according code to a new package.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Manuel Gómez

On Fri, 2 Oct 2015, Manuel Gómez wrote:

> In a post-AMP Haskell, however, retaining `return` in `Monad` does not
> serve any purpose: any `Monad` instance requires an `Applicative`
> instance, wherein `pure` must be defined, and it is a law required by
> all instances that they behave identically.  The only expressive purpose
> of `return` being in the `Monad` type class is providing an opportunity
> to break the laws the community expects for all instances of `Monad`.

We will get constant breakage this way. You mentioned Pointed class. If it
appears one day then your argument would translate to: We must acknowledge
that 'pure' was always wrong in Applicative. Then we will have an APP
(Applicative without 'pure' proposal) that again breaks lots of code
without a way to code for multiple versions of base.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Herbert Valerio Riedel

On Thu, 24 Sep 2015, Herbert Valerio Riedel wrote:

> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
>
> Monad of no `return` Proposal
> =============================

Btw. there were proposals of GHC extensions that allow class hierarchy
updates without much code breakage (class aliases) etc. Could we defer the
MRP until such extensions are implemented?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann
In reply to this post by Gregory Collins-3

On Mon, 5 Oct 2015, Gregory Collins wrote:

> Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few
> years:
>  *  After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import
>     Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere

I import them qualified and then define

    type CInt = CTypes.CInt

sometimes.

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

I was advised to always import time-1.5.

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

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

>  *  Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying
>     to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first
>     place)

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

>  *  Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where
>     anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions
>     of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle

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

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

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

>  *  To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not
>     older ones (this is a place where CPP use is actually justified)

I have not used them so far.


I have solved more complicated cases with conditional Hs-Source-Dirs:
    http://wiki.haskell.org/Cabal/Developer-FAQ#Adapt_to_different_systems_without_CPP

It's cumbersome but so far I managed most transitions without CPP.

(Nonetheless, MRP would require the complicated Hs-Source-Dirs solution
for far too many packages.)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Henning Thielemann
On Sun, Oct 18, 2015 at 2:24 PM, Henning Thielemann <[hidden email]> wrote:
Btw. there were proposals of GHC extensions that allow class hierarchy updates without much code breakage (class aliases) etc. Could we defer the MRP until such extensions are implemented?

There are three things entangled in your request that I'd like to uncouple.

1.) None of those proposals would actually have any impact here: `pure` is already a member of Applicative that people already define. `return` already has a definition in terms of `pure` as its default.

2.) This proposal is definitely being deferred in one sense, nothing can even happen on the warning front until 8.2 at the earliest under the "3 Release Policy" and in practice we'd probably push it back further still given the scope. So you have a couple of years before you'd even hear a peep from the compiler about this saying that hey maybe you might want to consider doing something.

3.) Finally, it isn't clear to me that we're going to be able to achieve a meaningful consensus on how to proceed with superclass defaults. We've been tossing proposals for them around for years. There are at least 3 of them in the wings, with both Richard Eisenberg and Conor McBride having different proposals that yield different end states with varying degrees of prescriptiveness about how they should be used, and some other folks who disbelieve it can be implemented at all in a way that works well with anything more complicated than a linear chain of instances. 

So while they don't apply to this item, I'm hesitant to incur such a proposal as a blocker on anything when there is no sign of termination in sight and no indication of which way that feature will break in terms of supplied functionality. 

That is a broader statement as while here they bring nothing to the table that would affect code written under this proposal, elsewhere they could help. -- If we had them at most eventually people would be able to consider (maybe) dropping the manual declaration of Functor, and possibly inline some of their definitions from Applicative into the Monad declaration (depending on which proposal wins favor if any, and if that version of the proposal always complains when it is used like Richard's variant), but the story of pure vs. return doesn't change meaningfully.

That said, if a version of the feature showed up over the next 2-3 years in GHC, we'd likely modify the Monoid-Semigroup Proposal to incorporate it as that proposal could benefit, but as above I'd hesitate to tie anything to the fate of a superclass default proposal.

Again, none of the changes being proposed have any impacts before 8.2 (or even 8.4 at last check.)

-Edward

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

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

Henning Thielemann
In reply to this post by Mario Blažević

On Fri, 2 Oct 2015, Mario Blažević wrote:

> The benefits of applicative do, if I understand the motivation
> correctly, are not so much to help in writing new code intended to be
> applicative. Instead it lets the programmer write in monadic style and at the
> same time enables the compiler to convert the code to applicative style if
> possible. This has the potential to automatically improve performance of
> legacy Haskell codebase, as well as any new beginner-friendly code that
> relies on syntactic sugar.

I see the benefit of ApplicativeDo in the short distance of the value
producer and the value naming. E.g. compare

liftA3
    (\x y z -> complicatedFunc x y z)
    produceX produceY produceZ

and

do x <- produceX
    y <- produceY
    z <- produceZ
    pure $ complicatedFunc x y z


Using the first style you may easily introduce inconsistencies if you
change the order of produceX, produceY, produceZ, whereas with the second
style you will certainly change whole lines and stay consistent this way.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Jules Bean

On 19 Oct 2015, at 20:52, Henning Thielemann <[hidden email]> wrote:

> I see the benefit of ApplicativeDo in the short distance of the value producer and the value naming. E.g. compare
>
> liftA3
>   (\x y z -> complicatedFunc x y z)
>   produceX produceY produceZ
>
> and
>
> do x <- produceX
>   y <- produceY
>   z <- produceZ
>   pure $ complicatedFunc x y z


Agreed. Furthermore I quite like the way applicative comprehensions read:

[complicatedFunc x y z | x <- produceX, y <- produceY, z <- produceZ ]

Also, what this example doesn’t show is that sometimes complicatedFunc is actually a complicated *expression* which merely mentions x,y,z each 1 or more times:

[ . . . some long code mentioning x . . .
  . . . and y and x again and now z . . .
  | x <- produceX,
    y <- produceY,
    z <- produceZ
 ]

As Henning says the tradeoffs here are all to do with drawing the eye correctly between the use of x,y,z and the binding of x y x.

There is also the fact that x y and z may not ‘naturally’ occur in the right order - the ordering of effects in the producers can easily be significant.

Jules


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

Geoffrey Mainland
In reply to this post by Bryan O'Sullivan
I am also a -1, and I share Bryan's concerns.

What worries me most is that we have started to see very valuable
members of our community publicly state that they are reducing their
community involvement. While technical disagreement has something to do
with their decisions, I suspect that it is the /process/ by which these
decisions have been made that is pushing them away. Whatever our
individual stances on AMP/FTP/MRP, I hope we can all agree that any
process that has this effect needs a hard look.

I consider myself a member of the Haskell community, but like Henrik and
Graham, I have not actively followed the libraries list. I was take by
surprise by AMP. When FTP appeared, I didn't speak up because I felt the
outcome was inevitable. I should have spoken up nonetheless; I am
speaking up now.

In effect, only those who actively follow the libraries list have had a
voice in these decisions. Maybe that is what the community wants. I hope
not. How then can people like me (and Henrik and Graham) have a say
without committing to actively following the libraries list?

We have a method to solve this: elected representatives. Right now the
Core Libraries Committee elects its own members; perhaps it is time for
that to change.

Let me throw out a few straw man proposals.

Proposal 1: Move to community election of the members of the Core
Libraries Committee. Yes, I know this would have its own issues.

Proposal 2: After a suitable period of discussion on the libraries list,
the Core Libraries Committee will summarize the arguments for and
against a proposal and post it, along with a (justified) preliminary
decision, to a low-traffic, announce-only email list. After another
suitable period of discussion, they will issue a final decision. What is
a suitable period of time? Perhaps that depends on the properties of the
proposal, such as whether it breaks backwards compatibility.

Proposal 3: A decision regarding any proposal that significantly affects
backwards compatibility is within the purview of the Haskell Prime
Committee, not the Core Libraries Committee.

Now I am not saying I feel strongly that all (or any) of these proposals
should be enacted (in fleshed out form), but I do think they are all
worth discussing.

Cheers,
Geoff

On 10/05/2015 10:59 AM, Bryan O'Sullivan wrote:

> I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.
>
> This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed – and to general approval, no less – on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.
>
> I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.
>
> Thanks,
> Bryan.
>
>> On Oct 5, 2015, at 7:32 AM, Gershom B <[hidden email]> wrote:
>>
>>> On October 5, 2015 at 6:00:00 AM, Simon Thompson ([hidden email]) wrote:
>>> Hello all. I write this to be a little provocative, but …
>>>
>>> It’s really interesting to have this discussion, which pulls in all sorts of well-made  
>>> points about orthogonality, teaching, the evolution of the language and so on, but it  
>>> simply goes to show that the process of evolving Haskell is profoundly broken.
>>>
>>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
>>> that would have a profound impact on systems that are commercially and potentially safety  
>>> critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility  
>>> of the Haskell community to its users and, indirectly, to its future.
>> Hi Simon. I do in fact think this is provocative :-P
>>
>> I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
>>
>> I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
>>
>> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
>>
>> —Gershom
>>
>> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.

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

Henrik Nilsson-2
Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable
 > members of our community publicly state that they are reducing their
 > community involvement.

That worries me too. A lot. To quote myself from an earlier
e-mail in this thread:

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

Geoffrey further wrote:

 > Proposal 3: A decision regarding any proposal that significantly
 > affects backwards compatibility is within the purview of the Haskell
 > Prime Committee, not the Core Libraries Committee.

I thus definitely support this, at least for anything related to
the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively
follow the libraries discussions did so because they simply did not
think that changes to the central libraries as defined in the Haskell
report, at least not breaking changes, were in the remit of the
libraries committee, and were happy to leave discussions on any
other libraries to the users of those libraries. And as a consequence
they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers,
books, what people have learned, or even the community itself, it is
time to very carefully think about what the appropriate processes
should be for going forward.

Best,

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

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

Augustsson, Lennart
I'd say, of course, libraries covered by the Haskell report are not in the remit of the libraries committee.

-----Original Message-----
From: Libraries [mailto:[hidden email]] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 09:25
To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B
Cc: [hidden email]; [hidden email] List; Graham Hutton; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable  > members of our community publicly state that they are reducing their  > community involvement.

That worries me too. A lot. To quote myself from an earlier e-mail in this thread:

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

Geoffrey further wrote:

 > Proposal 3: A decision regarding any proposal that significantly  > affects backwards compatibility is within the purview of the Haskell  > Prime Committee, not the Core Libraries Committee.

I thus definitely support this, at least for anything related to the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward.

Best,

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

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

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

Re: Breaking Changes and Long Term Support Haskell

Henrik Nilsson-2
In reply to this post by Henrik Nilsson-2
Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to
 > introduce new features or fix significant historical warts in the base
 > libraries - even if this requires breaking changes - and those who
 > insist on no significant breaking changes in new releases, regardless
 > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that
is then outlined (Long-Term Support Haskell), I don't think this is
an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it
very clear that they are not at all against any breaking change. But
they oppose breaking changes to Haskell itself, including central
libraries, as defined by the Haskell report, unless the benefits are
very compelling indeed.

Speaking for myself, I have had to clarify this position a number
of times now, as there has been a tendency by the some proponents of
the proposed changes to suggest that those who disagree are against
all changes, the long term implication being that Haskell would
"stagnate and die".

And in the light of the above, I felt compelled to clarify this
position again.

It's not about no more changes ever. It is about ensuring that
changes are truly worthwhile and have wide support.

Best,

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

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

RE: Breaking Changes and Long Term Support Haskell

Augustsson, Lennart
I'd like to vehemently agree with Henrik here. :)

Personally, I think AMP was the right thing to do, but I don't think FTP was the right thing.
And I don't think changes that break code are necessarily bad either, just some of them.

(To clarify, I'm against the Foldable class, but not Traversable.  It would have been quite feasible to have the latter, but not the former.)

  -- Lennart


-----Original Message-----
From: Haskell-prime [mailto:[hidden email]] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 11:17
To: [hidden email] List; Haskell Libraries
Subject: Re: Breaking Changes and Long Term Support Haskell

Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to  > introduce new features or fix significant historical warts in the base  > libraries - even if this requires breaking changes - and those who  > insist on no significant breaking changes in new releases, regardless  > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed.

Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die".

And in the light of the above, I felt compelled to clarify this position again.

It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support.

Best,

/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

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