Coming in without much OCaml experience, I don't really think this is a great demonstration of why this construct has value.<p>I don't really want to read a long form description of the OCaml implementation of modules. I want a comparison to the languages he dismissed at the beginning of the article, and a discussion of why this feature has some value that isn't provided by those languages.<p>Basically - This feels like a different take on generics to me. There might be a lot of value in how this is implemented when compared to generics in a language like Java/C#/Typescript, but I didn't find that content <i>anywhere</i> in the article...
Zig's compile time execution lets you do similar things I believe.<p>In Zig, structs and modules are equivalent, and type declarations can be manipulated at compile time just like any other value. That, among other things[1], lets you write:<p><pre><code> fn LinkedList(comptime T: type) type {
return struct {
pub const Node = struct {
prev: ?*Node,
next: ?*Node,
data: T,
};
first: ?*Node,
last: ?*Node,
len: usize,
};
}
</code></pre>
I wonder if there's anything that OCaml functors can do but this can't.<p>[1] for example, you can implement a very efficient printf that gives an error at compile time when the format string is invalid. See <a href="https://ziglang.org/documentation/master/#comptime" rel="nofollow">https://ziglang.org/documentation/master/#comptime</a> for more details.
Amusingly, I was precisely working today on extra-nice error messages for module type errors in OCaml. :)<p>My reaction to the title was "But they are not exotic, I use them every day!"<p>It's definitely the feature I miss the most every time I work in other languages, even presumable "advanced" ones, like Haskell. One notable attempt to add them elsewhere is "modular C"[1].<p>[1]: <a href="http://cmod.gforge.inria.fr/" rel="nofollow">http://cmod.gforge.inria.fr/</a>
Great read. It's too bad modules are pretty much an afterthought in most langs.<p>I really like research language 1ML's approach to modules[0]. This allows monomorphic types to be treated like values, avoiding all of OCaml's module syntax (which can be a bit complex and verbose).<p><a href="https://people.mpi-sws.org/~rossberg/1ml/1ml-extended.pdf" rel="nofollow">https://people.mpi-sws.org/~rossberg/1ml/1ml-extended.pdf</a>
Other than the syntax, I’m not sure I understand how this is different from any other object-oriented class definition. I suppose the ability to project the module into the local or top-level scope, but that seems more like syntactic sugar than anything meaningful. What am I missing here?
On the topic of modules, I recommend reading about modules in Newspeak: <a href="https://bracha.org/newspeak-modules.pdf" rel="nofollow">https://bracha.org/newspeak-modules.pdf</a><p>Modules (which are just top level classes and contain nested classes) have no import statement and no hard linked external dependencies. When you instantiate the module (~class) you pass in dependencies it needs.
> Modules as a language feature were first developed in Modula-2 and Pascal, which were developed as a way to demarcate units of compilation.<p>Actually Mesa.
You can do something similar in Rust to ML modules using traits and generic impls as module functors!<p><a href="https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8bebb69fa7898b13c731ccef158c0e4b" rel="nofollow">https://play.rust-lang.org/?version=stable&mode=debug&editio...</a><p>This can be really useful especially as traits with differing concrete types diverge, you can create a unified interface trait object to allow trait objects for things like container classes.
Looking forward to the series! I hope, in one of his "presents", he talks about Lisp conditions and signals, which have also inspired PL/I conditions, and go really back to the idea of an error handler in an operating system.<p>Unfortunately, Unix (and C) really botched signals by limiting their number in the user space (in particular, they cannot be stacked), and so the idea largely fell out of favor as an error-handling paradigm.
One thing I like about Perl is the module system.<p>A big helper is when the module interface uses named parameters and has sensible defaults for unspecified parameters. This allows the module designer to add features without breaking existing code and makes it easier for someone to integrate the module in the first place. Having the documentation built into the module itself is also a huge win.
I feel like I keep saying this every single PLT-related HN thread. Sorry for preaching, but I just can't resist. I think Agda is an excellent programming language, and it's a joy to write anything in. Its learning curve is steep at the beginning but once you gain experience how to write coinfinite programs, it's such a joy.<p>I think its module system is a huge bonus. It makes code a lot easier to organize and reason. It forces toplevel module X to be defined in X.agda so there is no argument what the module should be named or where it should be found.