<div dir="auto">I agree with Eric. Aside from the practically important concerns he raised, your proposed instance is not strictly lawful, which I find troubling for such an essential wired-in type.<div dir="auto"><br></div><div dir="auto">    pure id <*> undefined</div><div dir="auto">    = (mempty, id) <*> undefined</div><div dir="auto">    = (mempty <> fst undefined, id undefined)</div><div dir="auto">    = (undefined, undefined)</div><div dir="auto"><br></div><div dir="auto">But according to the Applicative identity law,</div><div dir="auto"><br></div><div dir="auto">    pure id <*> undefined = undefined</div><div dir="auto"><br></div><div dir="auto">That's similar, but not the same.</div><div dir="auto"><br></div><div dir="auto">Let me add that not only the Monad instance but also the Functor one is incompatible, because we require</div><div dir="auto"><br></div><div dir="auto">    fmap f x = pure f <*> x</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 26, 2019, 3:58 PM Tristan Wibberley <<a href="mailto:tristan.wibberley@gmail.com">tristan.wibberley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>Dear Haskell Libraries mailing list members,</div><div><br></div><div>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" rel="noreferrer">https://gitlab.haskell.org/ghc/ghc/merge_requests/1262</a> and it requires discussion via this mailing list.</div><div><br></div><div>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><br></div><div>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></div><div><br></div><div>--</div><div>Tristan<br></div></div>
</div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>