<div dir="ltr">Ah, here it is: <a href="https://www.reddit.com/r/haskell/comments/7nmcrj/what_evaluation_strategy_to_use_for_a_new/ds3ykie/">https://www.reddit.com/r/haskell/comments/7nmcrj/what_evaluation_strategy_to_use_for_a_new/ds3ykie/</a>. Relevant excerpt:<div><br>I often see people saying they can get away with working with a "Lazy" annotation in a strict language all the time. Strict languages with "opt-in" laziness tend to lack the courage of their conviction after making that statement, though. You can get a sense for how honest that appraisal is by looking at the definition of Monoid in their language. If you wanted to capture all of the power of a lazy language, it'd need to be marked Lazy in one or both of its arguments. If its only one then Dual gets hosed. (See many of the versions of scalaz) If neither then you dare not implement any or all via the Any or All monoid, lest you lose short-circuiting (&&) evaluation, if you have it at all. So you now have an abstraction, but dare not use it. You find that in a language that is strict, these notions like Monoid, Applicative, etc. all really need to pick up variants based on your strictness in each argument, and frankly, nobody bothers and it all gets swept under the rug.<div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 23, 2018 at 7:21 AM, Andrew Martin <span dir="ltr"><<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I feel the the way concerning being lazy as possible and being left-strict where there is a symmetric choice to be made. This seems to be a common theme is base, although I’ve never seen it officially endorsed. I have seen Edward Kmett talk about this on reddit (contrasting it with the Monoid classes in strict-by-default languages), but I cannot find the thread.<br><br><div id="m_3670218280626604199AppleMailSignature">Sent from my iPhone</div><div><div class="h5"><div><br>On May 22, 2018, at 7:57 PM, Tikhon Jelvis <<a href="mailto:tikhon@jelv.is" target="_blank">tikhon@jelv.is</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I think the extra laziness makes sense here—it matches the behavior of common functions like &&. My general expectation is that functions are as lazy as they can be and, in the case of operators with two arguments, that evaluation goes left-to-right. (Again like &&.)<div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 22, 2018 at 4:37 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think extra laziness here would be a bit surprising.<br>
<div><div class="m_3670218280626604199h5"><br>
On Tue, May 22, 2018 at 5:57 PM, Donnacha Oisín Kidney<br>
<<a href="mailto:mail@doisinkidney.com" target="_blank">mail@doisinkidney.com</a>> wrote:<br>
> The current semigroup instance for Maybe looks like this:<br>
><br>
> instance Semigroup a => Semigroup (Maybe a) where<br>
> Nothing <> b = b<br>
> a <> Nothing = a<br>
> Just a <> Just b = Just (a <> b)<br>
><br>
> However, it could be lazier:<br>
><br>
> instance Semigroup a => Semigroup (Maybe a) where<br>
> Nothing <> b = b<br>
> Just a <> b = Just (maybe a (a<>) b)<br>
><br>
> This causes different behaviour for Data.Semigroup.First and<br>
> Data.Monoid.First:<br>
><br>
> >>> Data.Monoid.getFirst . foldMap pure $ [1..]<br>
> Just 1<br>
> >>> fmap Data.Semigroup.getFirst . Data.Semigroup.getOption . foldMap<br>
> (pure.pure) $ [1..]<br>
> _|_<br>
><br>
> A different definition for `Option` gets back the old behaviour:<br>
><br>
> newtype LeftOption a = LeftOption { getLeftOption :: Maybe a }<br>
><br>
> instance Semigroup a => Semigroup (LeftOption a) where<br>
> LeftOption Nothing <> ys = ys<br>
> LeftOption (Just x) <> LeftOption ys = LeftOption (Just (maybe x (x<>)<br>
> ys))<br>
><br>
> instance Semigroup a => Monoid (LeftOption a) where<br>
> mempty = LeftOption Nothing<br>
> mappend = (<>)<br>
><br>
> >>> fmap Data.Semigroup.getFirst . getLeftOption . foldMap (LeftOption .<br>
> Just . Data.Semigroup.First) $ [1..]<br>
> Just 1<br>
><br>
> Is there any benefit to the extra strictness? Should this be changed?<br>
><br>
> Another consideration is that the definition could equivalently be<br>
> right-strict, to get the desired behaviour for Last, but I think the<br>
> left-strict definition probably follows the conventions more.<br>
><br>
> I originally posted this to reddit<br>
> (<a href="https://www.reddit.com/r/haskell/comments/8lbzan/semigroup_maybe_too_strict/" rel="noreferrer" target="_blank">https://www.reddit.com/r/hask<wbr>ell/comments/8lbzan/semigroup_<wbr>maybe_too_strict/</a>)<br>
> and was encouraged to post it here.<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
><br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a></span><br></div></blockquote></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</div>