OCaml Modules: Think Immutable Singletons | Hacker News Reader

OCaml Modules: Think Immutable Singletons

blog.eatonphil.com

49 pointseatonphil22 comments

One problem is that it first starts with a Person class, then it says nope, modules are not like this. So it increases the cognitive load for absolutely no reason.

Another problem is that an immutable singleton could have interesting properties, like it could have a type, it could be polymorphic (e.g. think Scala's objects), but this article presents Ocaml modules to be nothing more than namespaces. So first of all, that's not true and furthermore, I don't see the usefulness in that compared to any other language that can do namespaces. When reading about some construct of a language I don't know, I want to see how that construct is different or useful for me.

As I'm writing this, the article has 42 points and I'm left wondering why. I've long suspected that HN votes articles by keywords happening in the titles, without reading the articles.

> As I'm writing this, the article has 42 points and I'm left wondering why. I've long suspected that HN votes articles by keywords happening in the titles, without reading the articles.

I haven't read the article, but it would be great if whoever submits an article also had to enter one or more questions (with yes/no answers or one-word unambiguous answers) about it. Then, upon submitting a vote for the article, HN would prompt users to answer them. A suggestion to read the fine article would be given to people who cannot answer, and no upvote would happen.

Hacker News, circa 2015.

Someone writes a blog post, using JavaScript to explain how modules are used in OCaml. Just in the case it changed during the last 20 years or so.

Edit: I'm glad more people learn about OCaml. A few years ago, I kept hearing that no one will contribute to my open source OCaml projects...

Well... yeah. What do you want, it's trying to explain by analogy. If it used OCaml it'd be "ocaml modules are simple, they're just like ocaml modules" which is... unhelpful. They could have used C but then they'd have to implement a singleton pattern in C first at which point thats like a dozen things to explain.

You're glad about more people learning OCaml... but make fun of attempts to help people learn OCaml by comparing it to things they might know already?

Chances are that no one will contribute to any given project in any popular language either.

The OCaml code for the Person module in that post is not not idiomatic. Also, a module is quite different from a class or JS object and it would be more helpful to think about a module implementing an (abstract) data type like in C or other procedural languages. There is no inheritance with modules and no dynamic dispatch. Once compiled, there is no selection of functions/methods at runtime.

So how does an ocaml module compare to a Haskell type class?

Haskell's typeclasses automatically do dictionary passing for you; OCaml modules require you to specify the dictionary yourself. See http://okmij.org/ftp/Computation/typeclass.html

OCaml modules and Haskell type classes are quite separate, too. I would make more sense to compare OCaml and Haskell modules. Haskell type classes implement ad-hoc polymorphism and OCaml doesn't have that at all. You can't implement in OCaml something like a show function that works on integers and strings and list of integers and so on like in Haskell using the Show type class.

You sort of can with functors or GADTs.

Like you say, sort of. This would imply that you wrap all the basic types in a sum type. It's quite heavy. Using the PPX mechanism the compiler can also be extended to generate this code automatically but again, this isn't very natural at the moment.

In fact, OCaml modules do correspond to Haskell type class instances, and there are ways to extend the ML module system to support ad-hoc style polymorphism (http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf).

On the other hand, you can also use modules as a simple namespacing mechanism (as in Haskell modules). But this does not capture the full power of the module system.

Modules can be seen as a collection of types (abstract or otherwise) and functions acting upon those types. Very prosaically, this can just be a type parameterized dictionary (or vtable if that floats your boat).

Haskell's "constrained" types look like this

    c => a

where the type `a` requires access to the details of a constraint `c`. It turns out that constraints are merely type parameterized dictionaries of functions acting upon those types. We could reify them into concrete data types if we liked and then replace the fat arrow

    (Dict of c) -> a

and get something functionally equivalent.

Now, instead of doing that Haskell has the typeclass mechanism which allows the compiler to automatically generate and pass needed constraints based on a prolog-like logic that executes at compile time. This can be convenient but restricts the flexibility of these dictionaries.

ML modules can do some of the very same things but require the user to manually wire the proper module in at the right time instead of letting the compiler do it [0]. The benefit is that your modules are more modular and can support more sophistication.

[0] Caveat: this compiler automatic dictionary wiring will be enabled, in part, with OCaml's modular implicits which are coming down the pike soon.

This is pretty wacky. I cannot help but feel that it would be far better to just learn OCaml modules without this metaphor. It seems too far from meaningful.

I agree. The title is downright bizarre until you realize the article is consumed more by JS idiosyncrasies than about the OCaml modules.

Well, it certainly spent effort explaining JS oddities, but it's ostensibly about OCaml modules. So, it's either stream of consciousness and dependent on commentary to intuit meaning or merely failed in its goal.

Is JavaScript becoming a lingua franca, used to explain other completely unrelated languages?

Even if any given developer doesn't use it as a primary development language, then as something they need a little bit of to do something in a browser, so I'd bet most programmers have at least seen it. And even if you've never seen Javascript before, it's superficially similar to C++/Java/C# so you can kind of make sense of it in simple examples like this.

It's a sufficiently malleable language where you can express ideas from radically different languages with differing philosophies (FP, OO, immutability etc)

What I get from this article is that OCaml modules are sort of like browserify modules or ECMAScript 6 modules.

Cool... I guess?

ES6 modules aren't higher order AFAIK

Reply on news.ycombinator.com