Proposal: merge either into transformers

[Michael Snoyman]

To be clear, I'm not at all proposing changing the lazy WriterT, I'm only
talking about expressing the strict WriterT in terms of the strict StateT.


On Sun, Apr 27, 2014 at 5:19 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Note: Lazy.WriterT can be used in ways that bottom out with Strict.WriterTor the even stricter
> StateT writer variant.
>
> *e.g.*
>
> snd $ runWriter $ fix (tell [1] >>)
>
> -Edward
>
>
>
> On Sun, Apr 27, 2014 at 3:47 AM, Michael Snoyman <michael at snoyman.com>wrote:
>
>>
>>
>>
>> On Sat, Apr 26, 2014 at 9:57 PM, Ross Paterson <R.Paterson at city.ac.uk>wrote:
>>
>>> On Sat, Apr 26, 2014 at 09:12:12PM +0300, Michael Snoyman wrote:
>>> > I think it's worth resurrecting Gabriel's proposed modification to
>>> have the
>>> > strict writer transformer exposed as an abstract type, built on top of
>>> StateT
>>> > (or using the same implementation as StateT). I've been bitten by the
>>> laziness
>>> > of strict Writer in the past, and thanks to Gabriel's email, I knew
>>> how to
>>> > solve the problem. But I think many people will be misled by the name,
>>> > documentation improvements notwithstanding.
>>>
>>> Indeed it's a trap.  But an abstract type would be less transparent than
>>> the other transformers, and would be incompatible with the lazy WriterT
>>> in subtle ways.
>>>
>>> How about just deprecating strict WriterT in favour of strict StateT?
>>>
>>>
>> > would be incompatible with the lazy WriterT in subtle ways
>>
>> That would be troubling, but I'm not sure in which ways it's
>> incompatible. Do you have any examples?
>>
>> The advantage of having WriterT implemented in terms of strict StateT is
>> that many people will automatically get the fix when upgrading to
>> transformers 0.4. Also, the writer API itself is very convenient for many
>> common use cases, so it would be nice if there was a version available that
>> didn't leak memory.
>>
>> Michael
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140427/80ed680f/attachment.html>