mapM /= traverse?

[Edward Kmett]

We managed to show that the old counter-example of a mapM that works where
traverse that would blow the stack isn't an issue since
https://ghc.haskell.org/trac/ghc/ticket/8189 was resolved.

Consequently, we're looking at removing mapM entirely from the class and
just making it a top level definition.

To do that we'd need to deprecate redefinition of the method in instances
for a version or two. This would need a new form of deprecation, where you
deprecate redefinition but not use of a member of a class. (I think Herbert
filed an issue to create it, but I can't find it off hand.)

Once we can make that transition, then the constraints on mapM would relax
to the same as those for traverse. That would fix both the constraints and
the implementation going forward for everything, but we should probably
handle this particular case first or you won't see any benefit for a couple
of years.

-Edward

On Tue, May 12, 2015 at 11:58 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 12/05/2015 15:26, Edward Kmett wrote:
>
>> On Tue, May 12, 2015 at 3:58 AM, Simon Marlow <marlowsd at gmail.com
>> <mailto:marlowsd at gmail.com>> wrote:
>>
>>
>>     Yes, I'm not really concerned that mapM is a method of Traversable
>>     rather than just being an alias for traverse, but I'm wondering why
>>     we define it in the list instance rather than using the default.
>>
>>
>> We were pretty paranoid about introducing space or time regressions and
>> didn't have a proof that we wouldn't introduce them by changing
>> something there, so we left it alone.
>>
>
> Ok good, so it looks like the answer is "we could change it, but benchmark
> first".  I can do that.  Thanks!
>
> Cheers,
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150512/30cc93a0/attachment.html>