4 ms·
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 fol
by triska 8y ago
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.
- michielderhaeg 8y agoI find calling Haskell's type systen ad-hoc rather surprising. Would you care to elaborate on that?
- triska 8y agoFor 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-interferes-with-referential-transparency https://stackoverflow.com/questions/27019906/type-inference-... https://stackoverflow.com/questions/14865734/referential-transparency-with-polymorphism-in-haskell https://stackoverflow.com/questions/14865734/referential-tra...
- joel_ms 8y agoThey’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..)