<div dir="ltr">I use join a fair bit in IO!<div><br></div><div>Consider something where you to dig in an IORef, and compute what to do next.<br><br>join $ atomicModifyIORef someRef $ \case</div><div>  Foo y -> (Bar, doSomethingWith y)<br>  x -> (x, return ())<br><br>I can't run IO actions inside the atomicModifyIORef but I can give one back as the "extra" result from atomicModifyIORef, and do something I precomputed.<br><br>With the join there this collapses into one line, and I can often avoid a pair of redundant case statements.<br><br>Other patterns are for common patterns that _almost_ look like applicative usage, like</div><div><br></div><div>do</div><div>  x <- foo </div><div>  y <- bar</div><div>  baz x y</div><div><br></div><div>which can be expressed via<br><br>join $ baz <$> foo <*> bar<br><br>without naming all the intermediaries, whether this is good or not depends on how much you like giving transient names to things.<br><br>-Edward<br><br><br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2019 at 12:46 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Join actually also comes up in compiler engineering!</div></div><div dir="auto"><br></div><div dir="auto">Most normalized compiler reps: notably anf and cps, have a sort of flatness condition where you can’t have nested subexpressions (aka in many cases in strict languages this is where evaluation order becomes explicit ) and the join operation corresponds to a step in the flattening process for nested expression syntax when you do compiler transformations in this setting. </div><div dir="auto"><br></div><div dir="auto">This is in fact exactly why it’s pretty brutal to write the monad for an anf or cps syntax , you’re essentially specifying subexpression evaluation order for all pairs of syntax constructors! </div><div dir="auto"><br></div><div dir="auto"> And while join is not at the moment in the Monad typeclass because of newtype stuff, writing these monad instances is way saner in terms of the join operators rather than in terms of bind. At least in my biased perspective ;)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2019 at 4:37 AM Georgi Lyubenov <<a href="mailto:godzbanebane@gmail.com" target="_blank">godzbanebane@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">In general, if you want to <b>dynamically generate</b> actions depending on the result of an earlier action you will always encounter join/(>>=).<br>For example (with ReadPrec/Parser): <br>I want to first parse a character, and then parse the same character two more times.<br>numberAndThenThatManyAs = join (fmap (\c -> satisfy (==c) *> satisfy (==c)) char)<br><br>Of note:<br>* The example is contrived for simplicity's sake, but you do really need a Monad (and hence join) to perform stuff like this in general. A more practical example would be parsing command-line options that depend on previous options.<br>* Obviously it's way more humane to write this with do-syntax. (or (>>=) or something) - do { c <- char; satisfy (==c); satisfy (==c) }<br>* I'm not actually sure whether you need a Monad in this situation, maybe you could get away with just <a href="http://hackage.haskell.org/package/selective-0.3" target="_blank">selectives</a><br><br>=======</div><div dir="ltr"><br>Georgi</div>
_______________________________________________<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-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<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-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>