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

[Richard O'Keefe]

On Fri, 15 Mar 2019 at 03:32, Richard O'Keefe <raoknz at gmail.com> wrote:

> 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/cbb7ebb4/attachment-0001.html>