Proposal: merge either into transformers

[Edward Kmett]

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/f136ea5b/attachment.html>