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

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

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

mantkiew
I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in).

Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing?

Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes.

Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ‎Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...). 

--
Michał

[1] http://www.infoq.com/presentations/functional-techniques-complexity

On Mon, Oct 5, 2015 at 2: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.
>
> G
> --
> Gregory Collins <[hidden email]>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Language Change Management (was: 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


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

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

Bryan Richter-2
In reply to this post by mantkiew
On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote:
>
> Well, there are the *compat packages:
>
> Base-compat
> Transformers-compat
> Mtl-compat 
>
> Etc. They do centralize the ifdefs and give you compatibility with
> GHC 7.*. I recently adopted the last two ones and they work like
> a charm. I am yet to adopt base-compat, so I don't know what the
> experience is with it.

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? I never knew what the *-compat
packages were all about. If that's what they're designed to do, I have a
feeling they have not gotten *nearly* enough exposure.

[Apologies for possible cross-posting; this thread jumped into my inbox
from I-know-not-where and already has half a dozen CCs attached.]

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

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

Alexander Berntsen
In reply to this post by Nathan Bouscal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/10/15 20:50, Nathan Bouscal wrote:
> There have been a lot of objections based on the idea that
> learners will consult books that are out of date, but the number of
> learners affected by this is dwarfed by the number of learners who
> will use updated materials and be confused by this strange
> historical artifact. Permanently-enshrined historical artifacts
> accrete forever and cause linear confusion, whereas outdated
> materials are inevitably replaced such that the amount of confusion
> remains constant.
Thank you for making this point

I would be very saddened if the appeal to history (i.e. technical
debt) would halt our momentum. That's what happens to most things both
in and out of computer science. And it's honestly depressing.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1
9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl
Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w
6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H
FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI
xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC
YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w
p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4
Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V
LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s
y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx
3IMLL+8mPsvTnfWDj+NY
=Mwbu
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Tony Morris-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+1

On 06/10/15 08:29, Alexander Berntsen wrote:

> On 05/10/15 20:50, Nathan Bouscal wrote:
>> There have been a lot of objections based on the idea that
>> learners will consult books that are out of date, but the number
>> of learners affected by this is dwarfed by the number of
>> learners who will use updated materials and be confused by this
>> strange historical artifact. Permanently-enshrined historical
>> artifacts accrete forever and cause linear confusion, whereas
>> outdated materials are inevitably replaced such that the amount
>> of confusion remains constant.
> Thank you for making this point
>
> I would be very saddened if the appeal to history (i.e. technical
> debt) would halt our momentum. That's what happens to most things
> both in and out of computer science. And it's honestly depressing.
>  _______________________________________________ Haskell-Cafe
> mailing list [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWEvo3AAoJEFkczQCvdvv0BQMH/2oxlo35Y4oFw2ZYMMjmb8es
Asm7IrQCOoYRH10mgFhZiNPsZakRrEBsk6QD6iyIk6DGGoA7YBuQ2DwOE3Hzr2Ih
jelQbB0Lqs6P3bj5EibZ1qad+g0zR9RWkjp+7R+zsbhQ3cu4WITT0EI5nwLIacE3
xKmT9WuWcd166rRJrpFSs7gCzQwtWPHropQgnXttx/85Uw6zxA//EimUqsIaLPI7
Yu8IlxqpbICgq7uWni1f1EVajNEIk4qewezrlahrJuBMcBqZ7jAknMIO06UIGFjv
ZZm5lBRc+c++XmwSAVdo+5StiILzHftrlqsW3dVoJLvFFKdKYRDhd3auA+PB/Oo=
=ND0C
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Gregory Collins-3
In reply to this post by Bryan Richter-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]>

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

Re: Language Change Management (was: 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

mantkiew
In reply to this post by Bryan Richter-2
All I am saying is that these various *compat packages manage to
encapsulate the ifdefs to some degree.

Here's the record of my struggle [1]. Then came Edward K. and told me
to use transformers-compat [2]. Then Adam B. chimed in suggesting
mtl-compat [3]. That's it. All my IFDEFs related to this topic were
gone.

I looked at base-compat [4] and it's very interesting. The big question is:

**Why cannot normal base be written the same way as base-compat? **
It would then automatically provide compatibility across all GHC versions.

Michał

[1] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/
[2] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu0l6nf
[3] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu5g73q
[4] https://hackage.haskell.org/package/base-compat

On Mon, Oct 5, 2015 at 6:18 PM, Bryan Richter <[hidden email]> wrote:

> On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote:
>>
>> Well, there are the *compat packages:
>>
>> Base-compat
>> Transformers-compat
>> Mtl-compat
>>
>> Etc. They do centralize the ifdefs and give you compatibility with
>> GHC 7.*. I recently adopted the last two ones and they work like
>> a charm. I am yet to adopt base-compat, so I don't know what the
>> experience is with it.
>
> 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? I never knew what the *-compat
> packages were all about. If that's what they're designed to do, I have a
> feeling they have not gotten *nearly* enough exposure.
>
> [Apologies for possible cross-posting; this thread jumped into my inbox
> from I-know-not-where and already has half a dozen CCs attached.]
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Language Change Management (was: 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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

amindfv
In reply to this post by Alexander Berntsen
IMO, the "tech debt" you're talking about feels very small. We've already made the change that return = pure by default. The historical baggage that this proposal cleans up is just the fact that legacy code is able to define its own "return" without breaking (which must be the same as the definition of pure anyway).
     I am also moving from +0.5 to +0 on this.

Tom


> El 5 oct 2015, a las 18:29, Alexander Berntsen <[hidden email]> escribió:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>> On 05/10/15 20:50, Nathan Bouscal wrote:
>> There have been a lot of objections based on the idea that
>> learners will consult books that are out of date, but the number of
>> learners affected by this is dwarfed by the number of learners who
>> will use updated materials and be confused by this strange
>> historical artifact. Permanently-enshrined historical artifacts
>> accrete forever and cause linear confusion, whereas outdated
>> materials are inevitably replaced such that the amount of confusion
>> remains constant.
> Thank you for making this point
>
> I would be very saddened if the appeal to history (i.e. technical
> debt) would halt our momentum. That's what happens to most things both
> in and out of computer science. And it's honestly depressing.
> - --
> Alexander
> [hidden email]
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1
> 9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl
> Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w
> 6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H
> FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI
> xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC
> YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w
> p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4
> Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V
> LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s
> y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx
> 3IMLL+8mPsvTnfWDj+NY
> =Mwbu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

amindfv
In reply to this post by Phil Ruffwind
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Tony Morris-4
In reply to this post by amindfv
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -- I am going to do some logging, yay!
data Logs a =
  Logs a [a]
  deriving (Eq, Show)

- -- one log message
singlelog ::
  a
  -> Logs a
singlelog a =
  Logs a []

- -- two log messages
twologs ::
  a
  -> a
  -> Logs a
twologs a1 a2 =
  Logs a1 [a2]

class Semigroup a where
  (<>) ::
    a
    -> a
    -> a

- -- I can append logs
instance Semigroup (Logs a) where
  Logs h1 t1 <> Logs h2 t2 =
    Logs h1 (t1 ++ h2 : t2)

- -- I can map on Logs
instance Functor Logs where
  fmap f (Logs h t) =
    Logs (f h) (fmap f t)

- -- I will collect logs with a value
data WriteLogs l a =
  WriteLogs (Logs l) a
  deriving (Eq, Show)

- -- I can map the pair of logs and a value
instance Functor (WriteLogs l) where
  fmap f (WriteLogs l a) =
    WriteLogs l (f a)

singlewritelog ::
  l
  -> a
  -> WriteLogs l a
singlewritelog l a =
  WriteLogs (singlelog l) a

- -- Monad without return
class Bind f where
  (-<<) ::
    (a -> f b)
    -> f a
    -> f b

- -- Can I Applicativate WriteLogs? Let's see.
instance Applicative (WriteLogs l) where
  -- Well that was easy.
  WriteLogs l1 f <*> WriteLogs l2 a =
    WriteLogs (l1 <> l2) (f a)
  pure a =
    WriteLogs (error "wait, what goes here?") a
  -- Oh I guess I cannot Applicativate WriteLogs, but I can Apply them!

- -- Well there goes that idea.
- -- instance Monad (WriteLogs l) where

- -- Wait a minute, can I bind WriteLogs?
instance Bind (WriteLogs l) where
  -- Of course I can!
  f -<< WriteLogs l1 a =
    let WriteLogs l2 b = f a
    in WriteLogs (l1 <> l2) b

- -- OK here goes ...
myprogram ::
  WriteLogs String Int
myprogram =
  -- No instance for (Monad (WriteLogs String))
  -- RAR!, why does do-notation require extraneous constraints?!
  -- Oh that's right, Haskell is broken.
  -- Oh well, I guess I need to leave Prelude turned off and rewrite
the base libraries.
  do a <- singlewritelog "message" 18
     b <- WriteLogs (twologs "hi" "bye") 73
     WriteLogs (singlelog "exit") (a * b)

- -- One day, one day soon, I can move on.


On 06/10/15 11:20, [hidden email] wrote:

> IMO, the "tech debt" you're talking about feels very small. We've
> already made the change that return = pure by default. The
> historical baggage that this proposal cleans up is just the fact
> that legacy code is able to define its own "return" without
> breaking (which must be the same as the definition of pure
> anyway). I am also moving from +0.5 to +0 on this.
>
> Tom
>
>
>> El 5 oct 2015, a las 18:29, Alexander Berntsen
>> <[hidden email]> escribió:
>>
>>>> On 05/10/15 20:50, Nathan Bouscal wrote: There have been a
>>>> lot of objections based on the idea that learners will
>>>> consult books that are out of date, but the number of
>>>> learners affected by this is dwarfed by the number of
>>>> learners who will use updated materials and be confused by
>>>> this strange historical artifact. Permanently-enshrined
>>>> historical artifacts accrete forever and cause linear
>>>> confusion, whereas outdated materials are inevitably replaced
>>>> such that the amount of confusion remains constant.
> Thank you for making this point
>
> I would be very saddened if the appeal to history (i.e. technical
> debt) would halt our momentum. That's what happens to most things
> both in and out of computer science. And it's honestly depressing.
>> _______________________________________________ Haskell-Cafe
>> mailing list [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________ Haskell-Cafe
> mailing list [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWEylQAAoJEFkczQCvdvv08KMIAIGEwj6dQqnk8Z3zjFC1Vpvb
LTXdnzlcXCMXmIdzr9RaSGUKo52b3BPaP6EgFDJm8U/CJYQ/X8FAyy0gmKVJlru4
JQc4Y+CcGqz7+UwfYRlOOJDFNscigvGDj33N3hp3G/HuWfvllWJSx9n7gTqSrnXS
W/jTDN3sntJWiCdC+A5rLoqzH3eZ2LhwB0iL26DSfE1OLPyBK2kignKCjnMtRbEq
xY5vjx7xLQKzApRARIrBdDNVuXVRy+QQyGTGmdOKaLscNNrMzewcUr8LZLRG+6W7
RKA12y3etcVXGRlACHNn67mUKJIlKWX5PZSVsj07SZNWp3eyDctHfKuqYonfgJU=
=G8G2
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Rustom Mody
In reply to this post by Simon Thompson
On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <[hidden email]> wrote:
> littering the code with #ifdefs

>  Bonus points for keeping the #ifdefs centralized

Littering is the right word. "Bonus" is merely less negative points.

It is ironic that the beautiful Haskell should progress by
adopting the worst feature of C. #ifdef is a sticking-plaster
for non-portable code. It is inserted at global level, usually
to effect changes at the bottom of the code hierarchy. (Maybe
in Haskell it should be a monad, in competition with IO for
the outermost layer.)

Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed)
inescapably nonportable code, such as endianity, in compilation
units and #include files in a distinct part of the file system
tree selected by the shell.

Another trick is to use plain if rather than #if or #ifdef,
and let the compiler optimize away the unwanted side of the
branch.


In any event, #ifdef is, as Simon evidently agrees, telling
evidence of non-portability. It is hard to imagine an uglier
"solution" to keeping up with the drip-drip-drip of Haskell
evolution.

 
The python 2→3 transition may have caused some pain to some. However it would have been far more difficult if they had not provided tools like
Since the change here is trivial and pervasive why is such a tool not being considered?
[Or have I missed the discussion?]

In particular we can envisage a tool say 8to10 that has these modes (command-line flags)
--portable
--readable
--info

with the idea that
- portable is most unreadable (ifdef litter)
- readable is not portable -- generate a copy of the whole source tree that will have the changes and not be compatible for ghc < 7.8
  This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions
- info summarizes which files would change and how so that a suitable reorganization of the files/directories can be done prior to the switch
  This is for those library authors that would like to take the trouble to have a compatibility layer and have code as readable as possible overall

[Whether pure is really preferable to return is another matter --
For me one of the strongest criticisms of the python 2→3 switch is this that if they were going to break things anyhow why was the cleanup not more far-reaching?

Lets keep this note in these parentheses :-)

]


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

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

MRP, 3-year-support-window, and the non-requirement of CPP (was: 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!
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Mike Meyer
In reply to this post by Gregory Collins-3
On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <[hidden email]> wrote:
>    - 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 :).

Right - they have to be backported, and imply maintenance of multiple branches.

Python has been mentioned a couple of times. They did that, backporting functions that mimiced Python 3 functions to later Python 2 versions, which made the tools mentioned possible, or at least more capable.

I'll refer those wanting fewer breaking changes to Python. Getting language changes accepted by the PYthon community is hard. You need a use case for your change, you need to show that the case can't be handled cleanly by the language as it exists today, that it's common enough to justify the change, and that it won't tempt people to write uglier code than the current solution. If you want to break old code, all those bars get raised - a lot.

Or did, anyway, The result of following that was the Python 2/Python 3 split, which I don't think anybody thought was a good thing. Unavoidable, maybe - Python 3 had to break backwards compatibility, so they cleaned up everything along the way, and created tools to migrate code, and committed to maintaining both versions for an extended period of time. And the community was pretty badly splintered by this.

The one thing I think they got right is documenting the language change process with the entire PEP process. We seem to have wiki pages, with no editorial oversight, and pages show up in google searches after they've been incorporated into the language in a different form. Not quite as good a thing.

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

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

Herbert Valerio Riedel
In reply to this post by Rustom Mody
On 2015-10-06 at 05:43:43 +0200, Rustom Mody wrote:

[...]

> The python 2→3 transition may have caused some pain to some. However it
> would have been far more difficult if they had not provided tools like
> 2to3 and six:
> https://docs.python.org/2/library/2to3.html
> http://pythonhosted.org/six/
>
> Since the change here is trivial and pervasive why is such a tool not being
> considered?
> [Or have I missed the discussion?]

It is being considered! :-)

I'm in the process of collecting rewrite recipes and samples on

  https://github.com/hvr/Hs2010To201x

Alan is looking into how HaRe can be leveraged for this. I've refrained
from bringing this up, as I'm still waiting to reach a proof-of-concept
stage where we can confidently say that this actually works.


> In particular we can envisage a tool say 8to10 that has these modes
> (command-line flags)
> --portable
> --readable
> --info
>
> with the idea that
> - portable is most unreadable (ifdef litter)
> - readable is not portable -- generate a copy of the whole source tree that
> will have the changes and not be compatible for ghc < 7.8
>   This is for those library authors that prefer to maintain a clean code
> base and hell with earlier ghc versions
> - info summarizes which files would change and how so that a suitable
> reorganization of the files/directories can be done prior to the switch
>   This is for those library authors that would like to take the trouble to
> have a compatibility layer and have code as readable as possible overall
>
> [Whether pure is really preferable to return is another matter --
> For me one of the strongest criticisms of the python 2→3 switch is this
> that if they were going to break things anyhow why was the cleanup not more
> far-reaching?
>
> Lets keep this note in these parentheses :-)
>
> ]
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

--
"Elegance is not optional" -- Richard O'Keefe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
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

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

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

Re: Reducing the need for CPP

Kosyrev Serge
Ben Gamari <[hidden email]> writes:

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

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

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

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

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

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

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

Hmm..

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

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

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

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

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

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

This begs two questions:

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

   2. Why the hurry to push MRP through?

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

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

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

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

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

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

Best regards,

/Henrik

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




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

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

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

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