lazier writer monad

[David Feuer]

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.

    pure id <*> undefined
    = (mempty, id) <*> undefined
    = (mempty <> fst undefined, id undefined)
    = (undefined, undefined)

But according to the Applicative identity law,

    pure id <*> undefined = undefined

That's similar, but not the same.

Let me add that not only the Monad instance but also the Functor one is
incompatible, because we require

    fmap f x = pure f <*> x

On Wed, Jun 26, 2019, 3:58 PM Tristan Wibberley <tristan.wibberley at gmail.com>
wrote:

> Dear Haskell Libraries mailing list members,
>
> I've submitted a merge request for an increase in the laziness of the
> writer monad: https://gitlab.haskell.org/ghc/ghc/merge_requests/1262 and
> it requires discussion via this mailing list.
>
> 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.
>
> 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.
>
> --
> Tristan
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190626/79acecaf/attachment.html>