Live data from Hacker News

Functor, Applicative, and Monad

typeslogicscats.gitlab.io

41–50 of 125 posts

Re: Functor, Applicative, and Monad

#41
post #40

Maths is what you get when you limit all your variable names to single letters.

And make symbols mean different things in different situations, and sometimes reuse symbols for the same thing, and sometimes make sin(x+3) mean the variables s * i * n * (x+3) and sometimes mean taking the sine of x+3.

Mathematical language is worse specified than markdown and has a huge amount of ambiguity and requirement that you understand the context that you're working in.

It works fairly well for mathematicians, in terms of being concise to express complex ideas on a blackboard, but overall it's a mess.

Re: Functor, Applicative, and Monad

#42
post #40

Maths is what you get when you limit all your variable names to single letters.

And make symbols mean different things in different situations, and sometimes reuse symbols for the same thing, and sometimes make sin(x+3) mean the variables s * i * n * (x+3) and sometimes mean taking the sine of x+3. Mathematical language is worse specified than markdown and has a huge amount of ambiguity and requirement that you understand the context that you're working in. It works fairly well for mathematician…

And the naming convention is absolutely horrid. It seems the main criteria is .. it should sound clever.

Re: Functor, Applicative, and Monad

#43

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

Yeah this is a common problem. And the real problem is few people both understands the subject but remember the stumbling blocks to learning that subject. There is a Haskell book by Christopher Allen where I think he tested the book out on a friend who didn't know Haskell so that he could be sure that it made sense. That's probably the best way to create material like this.

Re: Functor, Applicative, and Monad

#44

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

You claim that OCaml programmers are already versed in category theory but that’s not correct. The first exposure usually comes with concurrency libraries such as Lwt which isn’t very old nor in the standard library, and it provides syntax sugar so you can start being productive right away. You can write perfectly fine production OCaml programs without knowing what a monad is. Some may, but a lot of OCaml devs don’t…

You can also use monads without knowing anything about categories. It's just a convenient programming pattern.

Re: Functor, Applicative, and Monad

#45

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

I found it useful (or at least educational). I've used Haskell before, but not much OCaml -- the let+, and+, and let* forms were new to me.

Re: Functor, Applicative, and Monad

#47
post #29
post #28

Earlier quoted context omitted.

> Having reusable functions that work just as well on lists, maybe/option, reader, io / promise or what have you means these type classes do a very good job at abstracting over data types. These are the purest forms of abstraction. This is where I get kinda lost. Can you give an example of such a reusable function that works for all these things which does something valuable?

traverse (for sequence-like structures) or cataM (for tree-like structures). They let you walk a data structure with an applicative or monadic operation and compose the monadicity in the way that obviously makes sense.

Thanks for this short explanation. The benefits of these patterns were not clear to me just from reading the article. Questiob: is the idea always to think in terms of types as groups of values + some operations on those types such that ?

Re: Functor, Applicative, and Monad

#48
post #29

Earlier quoted context omitted.

traverse (for sequence-like structures) or cataM (for tree-like structures). They let you walk a data structure with an applicative or monadic operation and compose the monadicity in the way that obviously makes sense.

Thanks for this short explanation. The benefits of these patterns were not clear to me just from reading the article. Questiob: is the idea always to think in terms of types as groups of values + some operations on those types such that ?

It's important not to think of types as just sets of values, because types are more semantic than that; two quite different types might have the same underlying values but they're different types because you use them to mean something different. A typeclass is one or two levels higher than a type, and yes, for a type to conform to a typeclass usually means that that type supports particular operations in a way that conforms to certain laws (e.g. a type `a` will have an instance of the monoid typeclass if there is a definition of `+` for `a` that is associative and a value `0` of type `a` that behaves as left and right identity wrt this `+`).

I'm not sure how important that is when working practically with them though. I tend to think of typeclasses as something like categories of types that behave similarly.

Re: Functor, Applicative, and Monad

#49

Earlier quoted context omitted.

Thank you for taking what seems to be an interesting approach to explaining these concepts. > I use OCaml in this tutorial, with some occurrences of Haskell. > My intention is for anyone familiar with the basics of typed functional programming to be able to follow along. I don't know OCaml or Haskell and I got lost very early on due to the unfamiliar syntax. Do you think your explanation would be easy to translate to…

Shrugs Well, Python is dynamically typed and C doesn't really have good polymorphism or first-class function support. Both polymorphism and first-class functions (with closures) are important for understanding functors, applicatives, and monads. I admit that I'm more fluent in OCaml than I am in Python or C, so please correct me if I'm mistaken.

Python and C would indeed be unsuitable. Maybe Rust (quite OCaml-like, but with a more C-like syntax) or Java/C#/Kotlin would let you present these ideas with a more "mainstream" syntax?

Re: Functor, Applicative, and Monad

#50
post #45

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

I found it useful (or at least educational). I've used Haskell before, but not much OCaml -- the let+, and+, and let* forms were new to me.

If I recall, they are very new to OCaml too.
Post reply on HN