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

[Charles Shuller]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190314/820eb431/attachment-0001.html>