Proposal: pare down traversable

[Edward Kmett]

I don't have benchmarks that support the removal of sequenceA at this time.
I also don't have ones that support its retention, but at this stage
removal has the higher burden of proof.

We should eventually be able to eventually kick sequence and mapM out of
the class and simultaneously weaken their constraints, so assuming that
much happens you'll eventually be able to use sequence as sequenceA. The
question then becomes if we'll be able to eliminate sequenceA as well, or
if it should remain in the class.

None of these migrations paths viably end with sequence being a member of
the class, though, so the best case is that we find `traverse id` is never
appreciably worse and can separately move sequence/sequenceA out of the
class. Otherwise we'd be left with the annoyance of defining sequenceA.

Unfortunately the same issue mentioned above regarding the relationship
between mapM and mapM_ applies mutatis mutandis to sequence and sequence_,
so we can't really weaken the constraint on sequence until the monad of no
return proposal extended with (>>) goes through, putting both potential
simplifications of the Traversable class on the same general clock.

-Edward

On Sat, Sep 26, 2015 at 5:32 PM, David Feuer <david.feuer at gmail.com> wrote:

> Argh. I'd love to be able to deprecate sequenceA sooner rather than later.
> Are there polymorphic recursive settings where sequenceA is more efficient
> than traverse id? If not, we can start sinking it immediately; if so, we
> have to wait for sequence to be ready to take its place.
> On Sep 26, 2015 5:21 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> Until we get rid of (>>) from Control.Monad and we can then rely upon
>> (*>) and (>>) having the same performance characteristics mapM_ and
>> traverse_ are not interchangeable. I realize you didn't say anything about
>> those functions, but hear me out.
>>
>> The tentative migration plan is, assuming the "monad of no return"
>> proposal goes through, to first eliminate (>>) then fix mapM_. This avoids
>> the very awkward intermediate state that would be a result of directly
>> implementing your proposal here where mapM_ needs a stronger constraint
>> (Monad) than mapM does, which would use Applicative!
>>
>> I therefore very strongly advocate waiting for the elimination of (>>)
>> through the monad of no return proposal before we proceed with any
>> simplification of Traversable.
>>
>> -Edward
>>
>> On Sat, Sep 26, 2015 at 5:05 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> Traversable currently has traverse, sequenceA, sequence, and mapM
>>> methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest
>>> that sequenceA be turned into a deprecated function and mapM be moved from
>>> Control.Monad to Data.Traversable and re-exported from Control.Monad.
>>>
>>> I expect most instance declarations to survive unchanged. The only CPP
>>> pain point will be that instances that define sequenceA will have to define
>>> sequence instead.
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150926/8f4ef7dc/attachment-0001.html>