If I want to extend List with additional functions, I can just do: include module type of List val flat_map : ('a -> 'b list) -> 'a list -> 'b list include List let flat_map f l = flatten (map f) l and that’s fine. But if I want to extend Format, this simple trick doesn’t work so well, because t…

Easy peasy! There is an OCaml idiom for that: include module type of struct include Format end To understand why that works, you need a bit of knowledge on the module type system. The basic idea is the following: the struct include X end dance forces the typechecker to “strengthen” the module sign…

Note that using module type of may lead to versioning difficulties and possible breakage: Serious OPAM package quality issues

The issue of strengthening module type of (or of having two versions) has been discussed on Mantis, see MPR#5241 and MPR#6307 . If I remember correctly, @lpw25 has opinions about it.

[image] yawaramin: Note that using module type of may lead to versioning difficulties and possible breakage: Serious OPAM package quality issues This is true if you use module type of ... in a contravariant position. Using it in a covariant position, as @c-cube does, is very common to extend …

I’d like to nominate this for FAQ status @yawaramin . Extending a module while keeping full type compatibility is an issue that, while it may not come up every day, is tricky to figure out when it does come up.

really neat, thank you! :crazy_face:

I’m not convinced module type of shoudl strengthen, since it would make impossible to get an non-strengthened type out of the module. The problem is that the idea of a “non-strengthened type” has no consistent definition. Trying to pretend that it does causes most of the problems with both module…

[image] lpw25: The problem is that the idea of a “non-strengthened type” has no consistent definition. I do not understand this. It has a pretty clear definition as far as I’m concerned, at least on the theoretical level. Arguably, the exact theory behind with module is not particularly clear…

It has a pretty clear definition as far as I’m concerned, at least on the theoretical level The underlying issue is that it produces different module types for modules with the same type. It is making distinctions between different syntactic representations of the same type – which breaks fundame…

Ok, I see your point, you want some module types to be indistinguishable, but currently module type of allows you to observe their differences. I understand the idea, and I agree these signatures should probably not be distinguishable. That being said, I’m a bit worried that we will lose some expre…

[image] lpw25: Here again two (pairs of) definitions that are equivalent are being distinguished based on their syntax. I like your discussion about the “issue” of module type of, and I find your last example easier to follow. But, nevertheless, I want to be sure I really understand the point…

Extend existing module

Learning

c-cube January 6, 2018, 2:26pm 7

really neat, thank you!

Topic		Replies	Views
ICFP and improvement of module language Learning	19	978	October 29, 2024
De-duplicating module signatures that depend on abstract data types Learning module	11	3415	May 24, 2019
Managing functor dependencies Learning	24	1528	September 24, 2021
Concise Module Syntax Community language-design , ideas	23	4623	January 5, 2018
Modules that extend modules from third-party packages Ecosystem package-design	2	2637	May 9, 2019

Extend existing module

Related topics