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

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

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

Jan-Willem Maessen


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

> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>
>> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email])
>> wrote:
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>>
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...
>
This is a fair point that comes up fairly often. The fact that CPP is
required to silence redundant import warnings is quite unfortunate.
Others languages have better stories in this area. One example is Rust,
which has a quite flexible `#[allow(...)]` pragma which can be used to
acknowledge and silence a wide variety of warnings and lints [1].

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

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

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

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

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

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

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

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

import Prelude hiding ((<$>))

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

-Jan-Willem Maessen

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

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

Herbert Valerio Riedel
In reply to this post by Erik Hesselink
On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.

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

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

Cheers,
  hvr

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://www.rust-lang.org/team.html
_______________________________________________
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`

Bardur Arantsson-2
In reply to this post by Erik Hesselink
On 10/06/2015 02:06 PM, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.
>

Ditto.

(At the very least for simple +1/-1 posts rather than posts that spell
out any particular pros/cons/etc.)

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] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Bardur Arantsson-2
In reply to this post by Henrik Nilsson-2
On 10/06/2015 01:32 PM, Henrik Nilsson wrote:
> Dear all,
>
[--snip--]
>
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.
>

This is an argument from FUD. If it's unquantifiable then it can (almost
by definition) neither count for nor against, can it?

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

Indeed.

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

I don't think that was ever the idea. (See other the other post by Erik.)

>
>   2. Why the hurry to push MRP through?
>

Personally, I don't think there's much need to push the actual
*breaking* change through, but I *do* think that deprecation warnings
should go in as quickly as possible.

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

Isn't that what we're trying to do on this very thread?

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

It seems to me that the community *is* being involved rather than being,
as you say, "involuntary field testers". (Again: see the very existence
of this thread).

Perhaps we should also be discussing what, exactly, is meant by
"community". It seems people have different ideas about that.

(For myself, I would certainly presume that being a member of the
community would include following along on at least a few mailing lists
or reddit or *somewhere* where all things Haskell get discussed.)

> If MRP is pushed through now, with a resurrection of
> HaskellPrime being imminent, Graham and I strongly believe
> that risks coming across to a very large part of the
> Haskell community as preempting proper process by facing
> the new HaskellPrime committee with (yet another) fait
> accompli.
>
> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.
>

As I've certainly mentioned in this thread, the previous committee
didn't actually accomplish very much [1]. I also note that much of what
they *did* get through was actually mostly already field-tested in GHC
beforehand. (So there goes that argument, I guess.)

Regards,

[1] Though what they did accomplish is very much appreciated. Here's the
list linked from the Wiki page:
https://prime.haskell.org/query?state=accepted&milestone=Haskell+2010&order=priority

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

Re: Reducing the need for CPP

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

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


_______________________________________________
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

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

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

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

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

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

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

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


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

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

data Maybe' a = Nothing' | Just' a

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

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

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

    return = pure -- "deprecated" since GHC 7.10

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

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

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


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

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

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

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

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


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

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

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


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

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

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



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

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


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

Herbert Valerio Riedel

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

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

[...]

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

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

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

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

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

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

Do you see any problems with this scheme?

_______________________________________________
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

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

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

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

[...]

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

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

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

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

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

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

Do you see any problems with this scheme?

_______________________________________________
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
In reply to this post by Bardur Arantsson-2
Hi,

Bardur Arantsson wrote:

 > This is an argument from FUD. If it's unquantifiable then it can
 > (almost by definition) neither count for nor against, can it?

Of course 25 years+ of legacy is there. Quantifiable or not.
And of course it must count if we wish Haskell to be taken
seriously and be increasingly successful. That is at least
the view of a significant part of the Haskell community.
And the way to account for it, both that which is quantifiable
and that which is not, is to make sure that fundamental
language changes are given due consideration in a forum
where all stakeholders are adequately represented.

 > Personally, I don't think there's much need to push the actual
 > *breaking* change through, but I *do* think that deprecation warnings
 > should go in as quickly as possible.

What would the point of that be unless MRP eventually will go through?
I am afraid it comes across as an attempt to preempt proper process.

I'm somewhat baffled, to say the least.

 > It seems to me that the community *is* being involved rather than
 > being, as you say, "involuntary field testers".

Well, there are many prominent people who I have not seen posting
here. There are others who only found out via facebook postings
and the like, alerted by people who like me feel this is not
a proper process for a breaking change. The fact that there now
is a discussion

 > As I've certainly mentioned in this thread, the previous committee
 > didn't actually accomplish very much [1].

Measuring "accomplishment" in terms of number of changes seems both
naive and worrying to me, I must say. Maybe the committee actually
accomplished a great deal by not breaking things unnecessarily, for example?

 > I also note that much of what they *did* get through was actually
 > mostly already field-tested in GHC beforehand.

But with only a couple of possible exceptions, those were not
breaking changes affecting pretty much every single user.

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

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


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

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

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

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

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

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

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

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

  import Control.Applicative (Applicative(..))

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

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

Cheers,
   S.

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

David Feuer
In reply to this post by Henrik Nilsson-2


On Oct 6, 2015 7:32 AM, "Henrik Nilsson" <[hidden email]> wrote:
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee

Many more people are on this mailing list than will be chosen for the committee. Those who are not chosen have useful perspectives as well.

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

As others have said, no one wants that.

> But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)

The Foldable/Traversable BBP indeed was not as well discussed as it should have been. AMP, on the other hand, was discussed extensively and publicly for months. I understand that some people need months of notice to prepare to participate in a discussion. Unfortunately, I don't think those people can always be included. Life moves too quickly for that. I do think it might be valuable to set up a moderated, extremely low volume mailing list for discussion of only the most important changes, with its messages forwarded to the general list.

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

No, and Haskell 2010 was, by most measures, a failure. It introduced no new language features (as far as I can recall) and only a few of the most conservative library changes imaginable. Standard Haskell has stagnated since 1998, 17 years ago. Haskell 2010 did not reflect the Haskell people used in their research our practical work then, and I think people are justified in their concern that the next standard may be similarly disappointing. One of the major problems is the (understandable, and in many ways productive) concentration of development effort in a single compiler. When there is only one modern Haskell implementation that is commonly used, it's hard to know how changes to the standard will affect other important implementation techniques, and therefore hard to justify any substantial changes. That was true in 2010, and it is, if anything, more true now.

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

I hope not. Haskell has gained an awful lot from the researchers, teachers, and developers who create it and use it. I hope we can work out an appropriate balance of inclusion, caution, and speed.


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

John Wiegley-2
In reply to this post by Henrik Nilsson-2
>>>>> Henrik Nilsson <[hidden email]> writes:

> Of course 25 years+ of legacy is there. Quantifiable or not. And of course
> it must count if we wish Haskell to be taken seriously and be increasingly
> successful. That is at least the view of a significant part of the Haskell
> community. And the way to account for it, both that which is quantifiable
> and that which is not, is to make sure that fundamental language changes are
> given due consideration in a forum where all stakeholders are adequately
> represented.

Henrik,

I do appreciate this point of view. 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. A new Prime committee is being
nominated, it is true, but that has happened before.

Arguments for stability might be seen by some as arguments to never change,
since the same pain we must endure now, will also have to be endured later.
Books and code will still be broken, teaching will still be made harder, etc.
A willingness to accept that pain shows concretely that a brighter future is
coming.

I'm very much against frivolous change, but I strongly want improvement. If it
means a progressive delivery of changes, or grouping them a bit more, that is
fine. I just worry when I see the "caution" argument used to put a break on
daring changes time and again, because otherwise, why should we change at all?

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.

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

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

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

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

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

Regards,
    Malcolm
_______________________________________________
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] Reducing the need for CPP

Adam Bergmark-2
In reply to this post by Bardur Arantsson-2


On Tue, Oct 6, 2015 at 6:16 PM, Bardur Arantsson <[hidden email]> wrote:
On 10/06/2015 11:11 AM, Johan Tibell wrote:
> It might be enough to just add a NOWARN <warning type> pragma that acts on
> a single line/expression. I've seen it in both C++ and Python linters and
> it works reasonably well and it's quite general.

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

I've thought of this in the past and it would be great to have. Another possible use case is to allow this for extensions as well, e.g. "Only allow UndecidableInstances for this declaration"



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


_______________________________________________
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

Mikhail Glushenkov-2
In reply to this post by Herbert Valerio Riedel
Hi,

On 6 October 2015 at 19:03, Herbert Valerio Riedel <[hidden email]> wrote:
>> In the specific case of MRP, I can offer you a Wall-perfect transition
>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>> cabal-file, [...]

Apropos, is there a similar option for AMP warnings? I would rather
use that than CPP.
_______________________________________________
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

Herbert Valerio Riedel
Hi,

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

Sure, added in GHC 7.8:

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


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

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

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

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

_______________________________________________
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

Christopher Allen
In reply to this post by Malcolm Wallace-2
Do those participating in this thread think sentiments like this are constructive or inclusive? Is this how we encourage participation from newer members of the community?

Framing this debate in terms of a programming pecking order is unprofessional. Many times, those higher in the ranks will prefer a more conservative approach, as experienced surgeons once resisted the introduction of the autoclave. 

The problem isn't the change; it's what the change costs you. Provide data and make your case. Talk about what it _costs_ you, show evidence for that cost, and describe what would make the change acceptable. Do it without talking down to a constructed "other" of the people who've neglected to make the same status display you've injected into this conversation. That could be valuable input to the discussion, so we would could weigh costs and benefits as a community. 

There _are_ costs associated with going ahead with MRP, especially for those with large 1mm LOC industrial codebases. This is partly why I'm lukewarm on the change, but I believe it needs to happen sooner or later and waiting for more 1mm LOC codebases to be born isn't going to make it any better. The suggestions that we consider the example of 2to3 I believe have been more constructive, particularly since we have this lovely language which lends itself so nicely to static analysis anyway.


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

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

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

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

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



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

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

Tom Ellis
In reply to this post by Gregory Collins-3
On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)

    http://hackage.haskell.org/package/time-compat
_______________________________________________
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`

Tom Ellis
In reply to this post by Gregory Collins-3
On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:

> On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <[hidden email]> wrote:
> > Hang on a moment, are you saying that all the people writing to argue
> > that these changes would require them to write dozens more #ifdef's
> > actually don't have to write any at all?
>
> 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
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)
>    - one of many various changes to Typeable in the GHC 7.* series
>    (deriving works better now, mkTyCon vs mkTyCon3, etc)
>    - 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)
>    - 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
>    - ==# and friends return Int# instead of Bool after GHC 7.8.1
>    - 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)

In fact I think all of these apart from the FFI one could be solved with a
-compat package, could they not?
_______________________________________________
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`

Mark Lentczner-2
In reply to this post by Herbert Valerio Riedel

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


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