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

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

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

Erik Hesselink
On 5 October 2015 at 20:58, Sven Panne <[hidden email]> wrote:

> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>>
>> [...] 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...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

Erik

[1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Johan Tibell-2
On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink <[hidden email]> wrote:
On 5 October 2015 at 20:58, Sven Panne <[hidden email]> wrote:
> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>>
>> [...] 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...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

No it doesn't, if you also don't want closed import lists (which you should).
 

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

Christopher Allen
In reply to this post by Johan Tibell-2
I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to date with GHC 7.10. AMP made things better, not harder, with respect to teaching Haskell. BBP required some explanation of "ignore this type, we're asserting a different one", but the positives are still better than the negatives.

Please don't use existing or forthcoming books as an excuse to do or not-do things. Do what's right for the users of the language.

On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell <[hidden email]> wrote:
On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <[hidden email]> wrote:

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <[hidden email]> wrote:
My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ  find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

On the libraries I maintain and have a copy of on my computer right now: 329


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




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

Peter Simons
In reply to this post by Sven Panne-2
Sven Panne <[hidden email]> writes:

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

Yes, the proper solution is slightly more complicated than just
importing Prelude.Compat [1]. You also have to specify "import
Prelude ()" -- or compile with NoImplicitPrelude, if you prefer
that kind of thing.

Best regards
Peter


[1] http://hackage.haskell.org/package/base-compat-0.8.2/docs/Prelude-Compat.html

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

Yitzchak Gale
In reply to this post by John Wiegley-2
John Wiegley wrote:
> You made a great argument, Henrik, and you've changed my enthusiastic +1 to
> +0, until it can be bundled with some other, more necessary, breaking change.

I, too, am hereby changing my +1 to a 0.

(Even though John himself eventually went back to +1.)

I am one of the people who would eventually pay a steep
price for this change. I voted +1 only because there seemed
to be a clear consensus to do it. I intended to express
with my vote that I am willing to pay that price if there
is such a consensus.

But since then, quite a few very prominent members of
the community have come out strongly against
this change. So I am now climbing back onto the fence,
which is where I will sit until/unless a consensus one
way or the other develops again.

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

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

Adam Foltzer
In reply to this post by Herbert Valerio Riedel
Thanks for splitting this off, as it really deserves its own conversation.

% find cryptol -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
      49
% find saw-script -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
     242

I introduced most of these in order to accommodate AMP, and now I learn that there is another proposal that is considered to be part-and-parcel with AMP where I will have to make yet more changes to the same code and presumably introduce another layer of #ifdefs. As proposed, I will spend 2*n hours implementing, testing, and releasing these changes. Had both changes been bundled, it would have been 2*(n+ε).

 Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all at once in e.g. `base-5.0`, breaking almost *every* single package out there at once.

I doubt the number of complaints-per-change would be fewer, but I'm strongly in favor of moving away from what feels like a treadmill that doesn't value the time of developers and that doesn't account for the more-than-sum-of-parts cost of the "constant flux".

Thanks,
Adam

On Mon, Oct 5, 2015 at 7:32 AM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> 2015-10-05 11:59 GMT+02:00 Simon Thompson <[hidden email]>:
>
>> [...] It’s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit
> annoying: Because of the constant flux of minor changes in the
> language and the libraries, I've reached the stage where I'm totally
> unable to tell if my code will work for the whole GHC 7.x series. The
> only way I see is doing heavy testing on Travis CI and littering the
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> keeping the #ifdefs centralized.  No clue how to do that...) This is
> less than satisfactory IMHO, and I would really prefer some other mode
> for introducing such changes: Perhaps these should be bundled and
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> comes in slightly larger, but more sensible chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be
> improved...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API).  One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!



 [1]: IMO, we need something to be used at the definition site providing
      desugaring rules, rather than requiring the use-site to enable a
      generalised desugaring mechanism; I've been told that Agda has an
      interesting solution to this in its base libraries via
      {-# LANGUAGE BUILTIN ... #-} pragmas.


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


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

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

Gregory Collins-3
In reply to this post by Sven Panne-2

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)
--
Gregory Collins <[hidden email]>

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

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

wren romano-2
In reply to this post by Adam Foltzer
On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <[hidden email]> wrote:
>>  Also I'm not sure if there would be less complaints if
>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>> at once.
>
> I doubt the number of complaints-per-change would be fewer, but I'm strongly
> in favor of moving away from what feels like a treadmill that doesn't value
> the time of developers and that doesn't account for the
> more-than-sum-of-parts cost of the "constant flux".

Broadly speaking, I'm a "fix it now rather than later" sort of person
in Haskell because I've seen how long things can linger before finally
getting fixed (even when everyone agrees on what the fix should be and
agrees that it should be done). However, as I mentioned in the
originating thread, I think that —at this point— when it comes to
AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
work out a comprehensive solution (as soon as possible), and then
enact all the changes at once when switching to
Haskell201X/base-5.0/whatevs. I understand the motivations for wanting
things to be field-tested before making it into the report, but I
don't think having a series of rapid incremental changes is the
correct approach here. Because we're dealing with the Prelude and the
core classes, the amount of breakage (and CPP used to paper over it)
here is much higher than our usual treadmill of changes; so we should
take that into account when planning how to roll the changes out.

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

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

Phil Ruffwind
In reply to this post by Adam Foltzer
Having so many #ifdefs isn't by itself a major problem.  Yes, it does
introduce a small increase in compilation time and the size of the
codebase.  The real cost is the developer time: every developer has to
come up with these these #ifdef clauses from scratch for every change
that gets made, tailored to their specific code.  As more and more get
added, it becomes more and more of a confusing mess.

It makes me wonder if this can be automated somehow.  It would be nice
to have a mechanism to alleviate this cost so that most developers
downstream (provided that the code was written in a reasonable manner)
only need to make a minimal effort to keep up, while still being able
to write code that works for a reasonably large range of GHC versions.
The burden of breaking changes right now is on the downstream
developers, but perhaps there could be a way to shift most of that
upstream to avoid this large duplication of effort.

Haskell should be allowed to evolve, but there also needs to be a
counterweight mechanism that provides stability in the face of
constant changes.  It would be something similar in spirit to
base-compat, but I don't think a library package alone is powerful
enough to solve the problem: a missing 'return' for example is not
something a library can just patch in.

I don't have any preference for "lots of small changes" vs "one big
change": in the former, there is a lot of overhead needed to keep
track of and fix these small changes; in the latter, there is a risk
of introducing a rift that fragments the community (cf Python 2 vs 3).
Maybe something in-between would be the best.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

amindfv
Another problem with #ifdefs (especially machine-generated ones) is that it makes code much harder to read. One of the things I love about Haskell is the ability to read code and literally see an author describe how they're thinking about the domain. #ifdefs make life less fun :)

Tom


> El 5 oct 2015, a las 21:00, Phil Ruffwind <[hidden email]> escribió:
>
> Having so many #ifdefs isn't by itself a major problem.  Yes, it does
> introduce a small increase in compilation time and the size of the
> codebase.  The real cost is the developer time: every developer has to
> come up with these these #ifdef clauses from scratch for every change
> that gets made, tailored to their specific code.  As more and more get
> added, it becomes more and more of a confusing mess.
>
> It makes me wonder if this can be automated somehow.  It would be nice
> to have a mechanism to alleviate this cost so that most developers
> downstream (provided that the code was written in a reasonable manner)
> only need to make a minimal effort to keep up, while still being able
> to write code that works for a reasonably large range of GHC versions.
> The burden of breaking changes right now is on the downstream
> developers, but perhaps there could be a way to shift most of that
> upstream to avoid this large duplication of effort.
>
> Haskell should be allowed to evolve, but there also needs to be a
> counterweight mechanism that provides stability in the face of
> constant changes.  It would be something similar in spirit to
> base-compat, but I don't think a library package alone is powerful
> enough to solve the problem: a missing 'return' for example is not
> something a library can just patch in.
>
> I don't have any preference for "lots of small changes" vs "one big
> change": in the former, there is a lot of overhead needed to keep
> track of and fix these small changes; in the latter, there is a risk
> of introducing a rift that fragments the community (cf Python 2 vs 3).
> Maybe something in-between would be the best.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ivan Lazar Miljenovic
In reply to this post by Gregory Collins-3
On 6 October 2015 at 11:40, Gregory Collins <[hidden email]> 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-locale-compat

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

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

Herbert Valerio Riedel
In reply to this post by Johan Tibell-2
On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <[hidden email]>
[...]

>> Strongly -1 from me also. My experience over the last couple of years is
>> that every GHC release breaks my libraries in annoying ways that require
>> CPP to fix:
>>
>> ~/personal/src/snap λ  find . -name '*.hs' | xargs egrep
>> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
>> 64

[...]

> On the libraries I maintain and have a copy of on my computer right now: 329


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


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

So when GHC 8.2 is released, your support-window requires you to support
GHC 7.10 and GHC 8.0 in addition to GHC 8.2.

At this point you'll be happy that you can start dropping those #ifdefs
you added for GHC 7.10 in your code in order to adapt to FTP & AMP.

And when you do *that*, you can also drop all your `return = pure`
methods overrides. (Because we prepared for MRP already in GHC 7.10 by
introducing the default implementation for `return`!)

This way, you don't need to introduce any CPP whatsoever due to MRP!


Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC
8.2 was just the *earliest theoretical* possible GHC in which this
*could* have happened. Realistically, this would happen at a much later
point, say GHC 8.6 or even later! Therefore, the scheme above would
actually work for 5-year time-windows! And there's even an idea on the
table to have a lawful `return = pure` method override be tolerated by
GHC even when `return` has already moved out of `Monad`!


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

    So please, keep on discussing!
_______________________________________________
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 Gregory Collins-3
On 10/06/2015 02:40 AM, 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

Having code meant for 4 different versions of a compiler be completely
-Wall clean is not a reasonable goal. This doesn't even happen for C++
compilers! (If my experience is anything to go by.)

It's also the reason -Werror is forbidden in Hackage uploads. (At least,
I think it is. Isn't it?)

Also, GHC 7.4 was released 2½ years ago. You may have my sympathies for
trying to support it, but unless you're getting paid for it I don't
think it's reasonable to expect you to. (If you're getting paid, then I
don't understand the complaint -- it might be a bit of make-work, but I
think everybody is subjected to that.)

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

"time-locale-compat" as Ivan pointed out.

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

I think these were because people learned that they could be done
better? (Also, I believe there was something here about these changes
being necessary for Safe Haskell, namely forbidding user-written instances?)

Is Typeable part of Haskell 2010?

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

Could you solve it with a qualified import? Then why use CPP?

(Incidentally, I think this is evidence that the Prelude should be an
explicit import like in PureScript.)

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

You don't *have* to shut up all warnings. (Unless we're talking
deprecation warnings *and* you're getting close to the cutoff point.)

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

Hoogle find ==# (and I've never heard it of before).

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

Well, yeah, new functions don't magically appear in old versions. I
don't anybody expects that :).

Regards,


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

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

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

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


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


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

[...]

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

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

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

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

    So please, keep on discussing!

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

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

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

-- Johan


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

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

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

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

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

 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
       
        -- in Control.Applicative
        {-# ALLOW redundant_import (<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

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

 2. Or alternatively we could make this a idea a bit more precise,
       
        -- in Control.Applicative
        {-# ALLOW redundant_import Prelude.(<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

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

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

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

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

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

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

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

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

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

- Ben


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

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

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Ben


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

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



_______________________________________________
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

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

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

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

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

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

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

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

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

Hmm..

--
с уважениeм / respectfully,
Косырев Серёга
_______________________________________________
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 Johan Tibell-2
Dear all,

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

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

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

This begs two questions:

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

   2. Why the hurry to push MRP through?

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

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

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

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

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

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

Best regards,

/Henrik

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




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

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

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

_______________________________________________
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
To question 1 my answer is NO!  I think voting to decide these kind of issues a terrible idea; we might as well throw dice.

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

Dear all,

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

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

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

This begs two questions:

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

   2. Why the hurry to push MRP through?

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

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

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

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

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

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

Best regards,

/Henrik

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




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

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

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

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

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

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

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

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

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

Erik Hesselink
In reply to this post by Henrik Nilsson-2
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.

Erik

On 6 October 2015 at 13:32, Henrik Nilsson
<[hidden email]> wrote:

> Dear all,
>
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee
>
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.
>
> It is also clear from the discussions over the last
> couple of weeks, on the Haskell libraries list as well
> as various other forums and social media, that MRP is
> highly contentions.
>
> This begs two questions:
>
>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?
>
>   2. Why the hurry to push MRP through?
>
> As to question 1, to Graham Hutton's and my knowledge,
> the libraries list and its voting process was originally
> set up for 3rd-party libraries in fptools. It seems to
> have experienced some form of "mission creep" since.
> Maybe that is understandable given that there was no
> obvious alternative as HaskellPrime has been defunct
> for a fair few years. But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)
> and also have very little time for engaging in long and
> complicated e-mail discussions that, from their
> perspective, happen at a completely random point in
> time and for which they thus have not had a chance to
> set aside time even if they wanted to participate.
>
> Just as one data point, AMP etc. mostly passed Graham
> and me by simply because a) we were too busy to notice
> and b) we simply didn't think there was a mandate for
> such massive overhauls outside of a process like
> HaskellPrime. And we are demonstrably not alone.
>
> This brings us to question 2. Now that HaskellPrime is
> being resurrected, why the hurry to push MRP through?
> Surely HaskellPrime is the forum where breaking
> changes like MRP should be discussed, allowing as much
> time as is necessary and allowing for an as wide range
> of perspectives as possible to properly be taken into
> account?
>
> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.
>
> If MRP is pushed through now, with a resurrection of
> HaskellPrime being imminent, Graham and I strongly believe
> that risks coming across to a very large part of the
> Haskell community as preempting proper process by facing
> the new HaskellPrime committee with (yet another) fait
> accompli.
>
> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.
>
> Best regards,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> [hidden email]
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> _______________________________________________
> 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
1 ... 3456789 ... 13