[m-users.] My experiences with inst declarations and making them more user-friendly

[Richard O'Keefe]

Why would you ever look for articles on how to translate Haskell's "do"
notation?
That's explained explicitly and clearly in section 3.14 of the report.
https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14
Once you understand ">>=" ">>" and "fail" you realise there's really no
other
way it could be done.

Although I've always found "do" as such to be pretty easy to read, when it
comes
to *writing* code, I prefer explicit use of >>= and >>, because it's
somehow easier
to think "algebraically" in plain Haskell.


On Fri, 15 Mar 2019 at 02:55, Charles Shuller <charles.shuller at gmail.com>
wrote:

> 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.
>
>
>    - Good syntactic sugar (highly constrained, small translation unit,
>    easy to explain to users):  hello[1:3] -> slice(hello, 1, 3).
>    - Bad syntactic sugar (broad in scope, large translation unit, hard to
>    explain to users):   Haskell do-block notation
>    - 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.
>
>
>
>
> ====A bit of an illustration on why Haskell made me think syntactic sugar
> is good for only very specific uses====
>
> 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:
>
>    1. Do Block starts out as a way to avoid monads, and can let a student
>    FEEL like hello-world is actually easy but...
>    2. 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.
>    1. 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).
>       2. I suspect learning the basics of category theory first, then the
>       Haskell implementation  may have been easier.
>       3. 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)
>    4. One also has to learn the "real" notation (because do-notation
>    isn't always appropriate)
>    5. 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.
>    6. 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
>       1. Which I found while trying to find articles on how to translate
>       do-notation into real notation
>
> Because of those reasons, I really wish I had never seen do-block notation.
>
>
>
> Cheers!
>
> Charles
>
> On Thu, Mar 14, 2019 at 6:11 AM Dirk Ziegemeyer <dirk at ziegemeyer.de>
> wrote:
>
>> Hi,
>>
>> 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:
>> 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. (
>> http://lists.mercurylang.org/archives/users/2015-March/007866.html)
>> 2. User-defined predicate declarations become much longer, because I have
>> to declare not only the type, but also subtype-insts.
>> 3. With mode-polymorphic versions of predicates, the error messages might
>> become very long and hard to read.
>>
>> I’m wondering if it might be possible to make insts more user-friendly.
>>
>> Maybe syntactic sugar for insts could make predicate declarations
>> shorter. For example:
>> 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.
>>
>> Do you think this kind of syntactic sugar would be - at least
>> theoretically - possible?
>>
>> Dirk
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.mercurylang.org
>> https://lists.mercurylang.org/listinfo/users
>>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190315/67e8ad5d/attachment.html>