Proposal: merge either into transformers

[Edward Kmett]

Come to think of it I'm not currently aware of anything that works
correctly with strict writer that doesn't work with the strict state
encoding.

-Edward


On Sun, Apr 27, 2014 at 10:51 AM, Michael Snoyman <michael at snoyman.com>wrote:

> 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.WriterT or 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/957db31b/attachment-0001.html>