Etcetera (was Re: Burning bridges)

[Edward Kmett]

In an earlier post in the thread I summarized a concrete list of what I
thought might best be entailed, which is to take the generalized versions
of the existing combinators from Data.Foldable and Data.Traversable, but
not to go off and make up new things to generalize -- those I think
rightfully belong in other proposals.

So, the intent of me and many of the others I interacted with in putting
forth the proposal was very much in the spirit of interpretation (2).

The were however, two combinators in Data.Foldable that I wondered if we
should include: Data.Foldable.concat and Data.Foldable.concatMap.

I'm pretty much neutral on their inclusion or exclusion.

Pros for including:
Consistency. Leaving them behind in Data.Foldable means that you get back
to importing with name collisions for just two combinators.

Cons for including:
concatMap is subsumed by foldMap
concat is subsumed by both fold and by join for its role in (++)
One can concoct a scenario where you use MonadPlus combinators to build up
a list and tear it down with the existing concat. This is arguably
"crossing the streams" as you are building up with one class and tearing
down with another class constraint with no law relating the two, and so
using the old Prelude 'concat' could help inference along -- otherwise why
were you invoking it in the first place?

Phrasing this as the intersection of the Foldable/Traversable API and the
Prelude is interesting, because it would leave a few fold-like combinators
in Data.Foldable alone. I'm somewhat neutral on whether we bring in the
rest of the foldlM, etc. but if we're bringing in Foldable, I'd like to at
least see foldMap, but that carries with it the caveat that foldMap
references Monoid, which is not currently in the Prelude (and traverse
references Applicative, also not currently in the Prelude).

Assuming the Applicative m => Monad m proposal goes through at the same
time (which seems exceedingly likely given the current polling, the
Applicative class would wind up in the Prelude, resolving the tension for
the latter, but exporting foldMap means we'd want at least the Monoid class
as well.

So to summarize the particular point in the design space that I've been
advocating and spell out some of its consequences:

The Prelude then exports Foldable(..), Traversable(..), Applicative(..),
and Monoid(..).
We upgrade the combinators in Prelude with the ones from Foldable and
Traversable that collide with the existing names -- along with whatever
resolution folks want on concat/concatMap.
Data.Foldable continues to export the few folds that weren't in the Prelude
or someone makes a case for bringing them in too, and it also re-exports
Foldable(..) and the combinators we moved, to facilitate the non-breakage
of existing code.
Data.Traversable re-exports Traversable(..) and provides foldMapDefault,
fmapDefault, mapAccumL and mapAccumR.
Data.Monoid would still continue to hold the existing monoids, (<>), and
re-exports Monoid(..).
Control.Applicative would still continue to export the instances,
Alternative(..), combinators, and re-exports Applicative(..).

-Edward



On Sun, May 26, 2013 at 12:38 AM, Mario Blažević <blamario at acanac.net>wrote:

> On 22/05/13 08:12 AM, Ian Lynagh wrote:
>
>> On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote:
>>
>>> I suggest that we start a poll for a single, concrete proposal.  If the
>>> poll forum is by email or similar, I further suggest that replies be
>>> limited strictly to +1/-1.
>>>
>> I think there are 4 things it has been suiggested that we might do:
>> * Generalise Prelude.mapM etc
>>
>
>     I've already given my +1 to this proposal, and I'm not likely to
> change my opinion. I have to say, though, that the "etc" above is a little
> sneaky. Now that the proposal has been overwhelmingly accepted, can we
> narrow it down? I can see four different interpretations of the "etc":
>
> 0. empty string;
> 1. "mapM_, sequence, and sequence_";
> 2. intersection of exports of Prelude, Foldable, and Traversable, which
> would include the above and also foldl, foldr, any, all, and, or, sum,
> product, maximum(By), minimum(By), concat(Map), elem, and notElem; and
> 3. every existing export of Prelude that can be generalized to Foldable or
> Traversable, which would be all of the above and then some others like map,
> filter, length, null, takeWhile, dropWhile, span, break, take, drop,
> splitAt, and probably some more.
>
>     It's best if I clarify that I'd be happy with either of the last two
> answers. I suspect the optimal solution lies somewhere between them.
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130526/cf66615a/attachment-0001.htm>