Monads for functional programming (1995) [pdf]

Re:Monads for functional programming (1995) [pdf] by triska on Sunday May 06, 2018 @04:00PM (#17008182)

In my experience, Haskell's comparatively complex and - arguably - also rather ad hoc type system can make a discussion of monads quite involved and hard to follow.

For those who approach Haskell with some Prolog or Mercury background, it may be useful to know that Prolog's Definite Clause Grammars (DCGs) are very similar to monads. In Prolog, a DCG clause of the form

    head -->
        goal_1,
        goal_2,
        ...,
        goal_n.

is implicitly augmented with 2 additional arguments that are threaded through as follows:

    head(S0, S) -->
        goal_1(S0, S1),
        goal_2(S1, S2),
        ...,
        goal_n(S_(n-1), S).

It is in these 2 arguments that you can implicitly pass around additional information such as counters, list differences, "global" variables, and states in general. Prolog provides dedicated syntax (called semicontext notation) to access these implicit arguments if needed. Often, they are simply threaded through implicitly throughout large portions of code without any modification.

Thus, it is obvious that DCGs, and hence monads, can save a lot of typing that would arise if you had to pass around these arguments explicitly. Also, they let you focus on the essence by making data that is only relevant to a small set of predicates (or functions) implicit in your programs.

It may be easier to understand these concepts if you can discuss them in isolation from a type system.

[ Parent | on HN ]

Re:Monads for functional programming (1995) [pdf] by michielderhaeg on Monday May 07, 2018 @02:59AM (#17010848)

I find calling Haskell's type systen ad-hoc rather surprising. Would you care to elaborate on that?

[ Parent | on HN ]

Re:Monads for functional programming (1995) [pdf] by triska on Monday May 07, 2018 @03:55AM (#17011063)

For example, aptly named ad-hoc polymorphism violates referential transparency:

    ( (7^7^7`mod`5`mod`2)==1, [False,True]!!(7^7^7`mod`5`mod`2) )

This yields:

    (True,False)

suggesting that the same arithmetic expression is both 1 and 0.

In GHC, there is a dedicated flag to spot such cases (-fwarn-type-defaults).

In general, the guarentees that the type system actually gives and also the ways to specify them appear somewhat unfinished and are also quite hard to understand, often necessitating semantic restrictions and syntactic extensions. For further examples, see for instance:

https://stackoverflow.com/questions/27019906/type-inference-...

https://stackoverflow.com/questions/14865734/referential-tra...

[ Parent | on HN ]

Re:Monads for functional programming (1995) [pdf] by joel_ms on Monday May 07, 2018 @05:23AM (#17011351)

They’re not the same expression though. The first gets defaulted to Integer, the second is specialized to Int by the (!!) function. (Integer is unbounded, Int is bounded)

The rest of your argument is fairly vague and unspecific. But I would suggest trying to understand the underlying type theory instead of focusing on the affordances that the type system makes for practicality and usability concerns. In my experience that makes it a lot clearer why the type inference works the ways it does in some of the weird cases. (That’s not to say that Haskell doesn’t have it’s warts..)

[ Parent | on HN ]