Proposal: merge either into transformers

Michael Snoyman michael at snoyman.com
Sun Apr 27 14:51:45 UTC 2014


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>


More information about the Libraries mailing list