<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi,</div><div class=""><br class=""></div>I think we should update the Applicative and Monad instances to document their strictness behaviors instead.<div class=""><br class=""></div><div class="">For code that relies on a particular strictness behavior I would recommend sticking with one of the modules in the transformers package: Control.Monad.Trans.Writer.Strict and Control.Monad.Trans.Writer.Lazy</div><div class=""><br class=""></div><div class="">As far as I can tell the current state of the PR updates the Applicative instance but not the Monad instance. Should this PR actually advance we should address that.</div><div class=""><br class=""></div><div class="">I agree that there are compositionally benefits to code that is as lazy as possible, however there are also space leak costs to that kind of code as well. I don’t think a simple rule like “as lazy as possible is best” is a good guiding principle. Changing the behavior now would just make the instance quite challenging to use portably and doesn’t make the instance more correct, just different.</div><div class=""><br class=""></div><div class="">Having a magic rule that datatypes with a single constructor match differently from datatypes with multiple constructors sounds like a readability nightmare. It’s already challenging to reason about the strictness behavior of programs. Making it harder like this would be a mistake. In addition adding or removing constructors from a datatype would have significant, non-local strictness effects to an existing program.</div><div class=""><br class=""></div><div class="">(The PR mentions something about Dependent Haskell and testing. Dependent Haskell isn’t going to replace testing and it isn’t going to make strictness easy to reason about.)</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Eric Mertens</div><div class="">glguy<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 26, 2019, at 12:57 PM, Tristan Wibberley <<a href="mailto:tristan.wibberley@gmail.com" class="">tristan.wibberley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class="">Dear Haskell Libraries mailing list members,</div><div class=""><br class=""></div><div class="">I've submitted a merge request for an increase in the laziness of the writer monad: <a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/1262" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/merge_requests/1262</a> and it requires discussion via this mailing list.</div><div class=""><br class=""></div><div class="">The link above includes an example of the motivation for this change and I hope you can all extrapolate to see the importance of this change, sufficient to not only accept this but to be moved to add a language flag, available within the content of a module's source file, to match unique constructors lazily throughout a module that uses it, lifting _|_ to the next least-defined value.</div><div class=""><br class=""></div><div class="">The core problem is that for the most handy and practical library interfaces, we need function results to be as well-defined as possible before a strict pattern match is required to choose between two constructors/values. There are several parts to providing that but one important part is that elements of patterns that cannot be unmatched should be lazily matched so the function's definition can be used without evaluating the function's arguments first. This avoids having to train users to always avoid patterns except after a let binding which would otherwise be necessary to establish a standard habit to lazily pattern match so the user base encourages each other to make their functions maximally useful.<br class=""></div><div class=""><br class=""></div><div class="">--</div><div class="">Tristan<br class=""></div></div>
</div></div>
_______________________________________________<br class="">Libraries mailing list<br class=""><a href="mailto:Libraries@haskell.org" class="">Libraries@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<br class=""></div></blockquote></div><br class=""></div></body></html>