Drastic Prelude changes imminent

[Edward Kmett]

On Sun, Feb 1, 2015 at 4:39 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> On Sun, Feb 1, 2015 at 12:25 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>>
>>   - the 'Monoid' class.  Monoids are a useful abstraction, but encoding
>>> them as a Haskell class is very much a compromise (in my mind, anyway).
>>> Keeping them in their own module seems like a good idea.
>>>
>> Monoid in Prelude is a result of the AMP, and that's not going to change
>> without breaking code even more, or introducing orphans. Neither of these
>> are going to happen: BBP has nothing to do with it.
>>
>>
>
> Really?  This is not obvious at all.  Is it because of the odd
> `Applicative` instance for pairs? I am saying 'odd' because there are no
> similar instances for tuples of higher arity;  there are also no instance
> for `Monad` for the same type, which makes as much sense, I guess.
> Obviously this is just an opinion, but I don't think these instances fit
> pairs naturally, and make for confusing looking code.
>

instance Monoid m => Monad ((,) m)

is the "unnamed" writer monad that corresponds to the

instance Monad ((->) m)

reader monad.

FWIW- On the Comonad side the roles interchange:

instance Monoid m => Comonad ((->) m)
instance Comonad ((,) m)

Both naturally arise in work on recursion schemes.

The same sort of concern lead to

instance Monad (Either a)

a year or two ago unencumbered by Error.

> Of course, I can generally work around all of those, so not a big deal.
>>> However,  it'd be nice if we could come up with a design that, more or
>>> less, the whole community thinks is a good one.
>>>
>> I understand why you feel that way, but it's simply impossible to do in
>> any scalable or sensible way in general. Why do we need a unanimous vote
>> here? Or, by this reasoning, when would we *not* need a unanimous vote?
>>
>> Even 80% in agreement is literally a supermajority beyond what you need
>> in almost any liberal democracy in the world to affect change, for example.
>> If we set our standards that high, it's not only slightly ridiculous, it's
>> tantamount to making sure nothing ever changes.
>>
>> Pleasing all the people all the time is just never going to be possible.
>>
>

>
>>
> Agreed.  The benefit of getting a design that is understood and accepted
> by most of the community is 1) when we use the language we feel it is
> awesome, and not an uneasy compromise; 2) when we introduce new folks to
> Haskell, we can explain and defend the various design decisions, 3) when
> newcomers look for examples of how to do things, they will look in the
> standard libraries.   I wouldn't give `Foldable` as an example of how to
> design a type-class.
>

If we can find a longer term path to get a more minimal Foldable without
compromising on performance, I'd love to head towards a more minimal
definition. After a year and a half of looking, I'm somewhat cynical about
its attainability, and there is a certain appeal to being able to offer
folks the escape hatch of not having to take slower implementations than
what they know they could have if something else in the class.


> I'd be much happier with changes that actually improve the overall design
> even at the price of breaking code.  I feel that the BBP does not improve
> the overall state of the design, and just reshuffles things a bit which,
> for me, has no benefit.
>

The benefit of the new state is that we can point to a very simple guiding
principle when figuring out what will conflict with the Prelude:

*"The Prelude now causes no import conflicts with any names anywhere in
base."*

This is a much more desirable and teachable end-state than a version of
that statement that has 30+ caveats.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150201/fb4f5f41/attachment.html>