<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 4:15 PM, Ross Paterson <span dir="ltr"><<a href="mailto:R.Paterson@city.ac.uk" target="_blank">R.Paterson@city.ac.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sun, Apr 27, 2014 at 10:47:56AM +0300, Michael Snoyman wrote:<br>
> On Sat, Apr 26, 2014 at 9:57 PM, Ross Paterson <<a href="mailto:R.Paterson@city.ac.uk">R.Paterson@city.ac.uk</a>> wrote:<br>
</div><div class="">> > would be incompatible with the lazy WriterT in subtle ways<br>
><br>
> That would be troubling, but I'm not sure in which ways it's incompatible. Do<br>
> you have any examples?<br>
<br>
</div>The Applicative and Alternative instances would have different contexts, and<br>
there would be no instances for Foldable, Traversable, Eq, Ord, Read or Show.<br>
<div class=""><br></div></blockquote><div><br></div><div>If we have deprecation of the module in its entirety on the table, I think it's acceptable to consider dropping some instances. However, I don't see Eq, Ord, Read, or Show instances for strict WriterT in transformers 0.3. Applicative seems like it should be identical in behavior to what we have right now. I'm not completely certain, but it seems the same is true for Alternative.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> The advantage of having WriterT implemented in terms of strict StateT<br>
> is that many people will automatically get the fix when upgrading<br>
> to transformers 0.4.  Also, the writer API itself is very convenient<br>
> for many common use cases, so it would be nice if there was a version<br>
> available that didn't leak memory.<br>
<br>
</div>Invisibly increasing strictness cuts both ways: some people get space<br>
savings, while others get non-termination.  (Although one might say<br>
they're not using it properly, that seems a harsh punishment.)  But I'm<br>
more concerned about the complication.  Currently the transformers are<br>
transparent, and people can think about the type structure of the monad<br>
they're building.  This very transformer is already there; it seems<br>
simpler to direct people to it instead of having another copy.  The API<br>
point is an issue, though.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Here's the question I'd ask, which I honestly don't know the answer to. We have three proposed WriterT implementations: lazy, current-strict, and state-strict. We have two conflicting desires: program termination and space savings. We know there are cases where lazy allows termination where state-strict does not. We know there are cases where state-strict allows space savings where neither lazy nor current-strict do.</div>

<div><br></div><div>The question is: are there cases where current-strict:</div><div><br></div><div>1. Gives space savings that lazy does not?</div><div>2. Gives termination where state-strict does not?</div><div><br></div>

<div>I *think* the answers to these questions are "no" and "yes", meaning that current-strict in its current form can *always* be replaced by lazy, without losing anything. If that's the case, I'd say this is a very simple transition in 0.4.</div>

<div><br></div><div>Note that we've been discussing all of this in terms of WriterT, but the same exact discussion should apply to RWST.</div><div><br></div><div>Michael</div></div></div></div>