<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Why would you ever look for articles on how to translate Haskell's "do" notation?</div><div class="gmail_default" style="font-family:monospace,monospace">That's explained explicitly and clearly in section 3.14 of the report.</div><div class="gmail_default" style="font-family:monospace,monospace"><a href="https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14">https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14</a><br></div><div class="gmail_default" style="font-family:monospace,monospace">Once you understand ">>=" ">>" and "fail" you realise there's really no other<br></div><div class="gmail_default" style="font-family:monospace,monospace">way it could be done.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Although I've always found "do" as such to be pretty easy to read, when it comes</div><div class="gmail_default" style="font-family:monospace,monospace">to *writing* code, I prefer explicit use of >>= and >>, because it's somehow easier</div><div class="gmail_default" style="font-family:monospace,monospace">to think "algebraically" in plain Haskell.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Mar 2019 at 02:55, Charles Shuller <<a href="mailto:charles.shuller@gmail.com">charles.shuller@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"><div>Regarding syntactic sugar:   Most of the syntactic sugar I've encountered has been a source of problems, not a resolution for them.   Of course, this may just be because "good" semantic sugar is completely transparent, and never gets in my way, but it seems the most difficult "features" and biggest sources of bugs I've encountered in many languages is a direct result of the semantic sugar.<br></div><div><br></div><div><ul><li>Good syntactic sugar (highly constrained, small translation unit, easy to explain to users):  hello[1:3] -> slice(hello, 1, 3).</li><li>Bad syntactic sugar (broad in scope, large translation unit, hard to explain to users):   Haskell do-block notation</li><li>Bad syntactic sugar (limited in scope, large translation unit, hard to explain to users): Async and Await in JavaScript -- These wind up being small words that wrap things up in promises, and using them properly WITHOUT already knowing about how promises work is next to impossible.<br></li></ul></div><div>    <br></div><div><br></div><div><br></div><div>====A bit of an illustration on why Haskell made me think syntactic sugar is good for only very specific uses====</div><div><br></div><div>As an example of bad syntactic sugar, I've found Haskell's do-block notation to be a truly horrifying experience for the following reasons:<br></div><ol><li>Do Block starts out as a way to avoid monads, and can let a student FEEL like hello-world is actually easy but...</li><li>One still has build up an intuitive understanding of the theoretical framework for monads for any real work, since Haskell libraries are chock full of them, and assume users know all about them and love them.<br></li><ol><li>By this I am referring, not to category theory, but the various functions monads are required to support and their proper use, all of which are higher-ordered (in that they accept or produce monads).</li><li>I suspect learning the basics of category theory first, then the Haskell implementation  may have been easier.<br></li></ol><li>One then has to learn the do-block notation and what that means in terms of the underlying functions (because Haskell pedagogy currently focuses on this, and almost all tutorials are built around it)<br></li><li>One also has to learn the "real" notation (because do-notation isn't always appropriate)<br></li><li>Finally, One has to learn to "de-sugar" do-block notation while reading it, because many problems are simplified (or move from impossible to possible) with the de-sugared version.</li><li>Maybe advanced users love do-notation and find it really beneficial, but most of the web-pages I see about do-blocks argue strongly against using do-notation except in the most extreme circumstances</li><ol><li>Which I found while trying to find articles on how to translate do-notation into real notation<br></li></ol></ol><div>Because of those reasons, I really wish I had never seen do-block notation.<br></div><div><br></div><div><br></div><div><br></div><div>Cheers!</div><div><br></div><div>Charles<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 6:11 AM Dirk Ziegemeyer <<a href="mailto:dirk@ziegemeyer.de" target="_blank">dirk@ziegemeyer.de</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">Hi,<br>
<br>
from time to time I try to take advantage of Mercury’s insts to allow for more static error checking. Usually these tries end very fast because of these reasons:<br>
1. The standard library predicates (e.g. list, map, foldl) don’t preserve subtype-insts. I have to write mode-polymorphic version of these predicates to go on. These mode-polymorphic predicate declarations are much longer and therefore harder to understand. (<a href="http://lists.mercurylang.org/archives/users/2015-March/007866.html" rel="noreferrer" target="_blank">http://lists.mercurylang.org/archives/users/2015-March/007866.html</a>)<br>
2. User-defined predicate declarations become much longer, because I have to declare not only the type, but also subtype-insts.<br>
3. With mode-polymorphic versions of predicates, the error messages might become very long and hard to read.<br>
<br>
I’m wondering if it might be possible to make insts more user-friendly.<br>
<br>
Maybe syntactic sugar for insts could make predicate declarations shorter. For example:<br>
Allow inst non_empty_list to be defined on type-level instead of inst-level. The compiler should notice that type non_empty_list is nothing else than type list which has an attached inst non_empty_list.<br>
<br>
Do you think this kind of syntactic sugar would be - at least theoretically - possible?<br>
<br>
Dirk<br>
<br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.mercurylang.org" target="_blank">users@lists.mercurylang.org</a><br>
<a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank">https://lists.mercurylang.org/listinfo/users</a><br>
</blockquote></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.mercurylang.org" target="_blank">users@lists.mercurylang.org</a><br>
<a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank">https://lists.mercurylang.org/listinfo/users</a><br>
</blockquote></div>