Meaning of the word 'module'?

Learning
1

I am a bit confused by the word ‘module’. My initial understanding of the word ‘module’ is that we want to define a module, i.e.

module foo = struct ... end

However, in OCaml - The module system we have the following example:

# module Set =
    functor (Elt: ORDERED_TYPE) ->
      struct
        type element = Elt.t
        type set = element list
        let empty = []
        let rec add x s =
          match s with
            [] -> [x]
          | hd::tl ->
             match Elt.compare x hd with
               Equal   -> s         (* x is already in s *)
             | Less    -> x :: s    (* x is smaller than all elements of s *)
             | Greater -> hd :: add x tl
        let rec member x s =
          match s with
            [] -> false
          | hd::tl ->
              match Elt.compare x hd with
                Equal   -> true     (* x belongs to s *)
              | Less    -> false    (* x is smaller than all elements of s *)
              | Greater -> member x tl
      end;;
module Set :
  functor (Elt : ORDERED_TYPE) ->
    sig
      type element = Elt.t
      type set = element list
      val empty : 'a list
      val add : Elt.t -> Elt.t list -> Elt.t list
      val member : Elt.t -> Elt.t list -> bool
    end

In particular, let us look at the type of module Set, it is a functor which takes one “module” as input, and produces a 2nd “module” as output. This is very different from say, what a Java package or a Rust module is.

I am trying to think of the correct way to understand the word “module” ; is it as follows?

We have two worlds: values & modules.

In the values world, we have: primitives + records + enums, types, functions.
In the modules world, we have: structs, signatures, functors.

In such an model, the word ‘module’ merely means “we are now going to define something in the ‘modules world’” ?

Is this the right way to think of the keyword ‘modules’ ? If not, what is the correct interpretation ?

2 Likes
2

I think it is roughly correct. Somewhat imprecisely, in OCaml you have:

  • core language: values (with first-class functions) + types;
  • module language: modules (with first-class functors) + module types;
  • class language: classes + class types

Cheers,
Nicolas

1 Like
3

We can definitely define functions that take objects[1] as input and produce objects as output.

Any intuition on why there is not a special name for this in class-land ?

[1] here referring to the OCaml object keyword

4

This is a bit vague, but as I see it, objects and object types belong to the core language, not to the class language. The reason is that immediate objects can be treated like any other value of the core language, and similarly object types can be used anywhere where a type of the core language can be used. Classes and class types, on the other hand, live in their own “universe” and cannot be mixed freely with the constructs of the core language.

Cheers,
Nicolas

3 Likes
5

I guess that generic programming of Java or C#, we can get close. See Set<E>in Java. But it is not equivalent. Here E is not bound to ORDERED_TYPE and only the generic equality among objects. And if we try to use Set<E extends ORDERED_TYPE> to support fancy comparison, this will break (E methods will still have methods which have fixed typed arguments), and we couldn’t describe a diadic function (compare) with equal type arguments. Then if E has a method .compare(int a), it can’t be used with strings.