2 ms·

Have you looked into the "first class modules" system used by ocaml? AFAIK it's the only language of its maturity to use something like it. It's very powerful w

Have you looked into the "first class modules" system used by ocaml? AFAIK it's the only language of its maturity to use something like it. It's very powerful without adding mandatory complexity. But because basically no one comes to it with prior experience in a similar approach, it's hard to gauge how powerful, or when the added complexity of using it fully is actually worth it.

matheusmoreira 3y ago
I have! I didn't reflect much on it though because I'm focused on creating a dynamic language. Perhaps I did not understand it? Another interesting concept I ran into while researching modules is parameterized modules. Essentially, modules that take their dependencies as arguments. The modular equivalent to dependency injection I suppose. Instead of a module importing by symbol a specific library as a dependency and some package manager resolving it to actual files in the load path later on, the programmer explicitly loads the library and passes it to the module as an argument. Instead of the symbolic imports we're all used to: (import lib); lib imports lib2 internally Module importing becomes analogous to function calls which construct an instance of the module given its dependencies: (import (lib2)) (import (lib lib2)) This is really elegant and more or less reifies package management into the language. However, it presents serious ergonomics issues because it forces the programmer to deal with all these package management and library loading details. The truth is we want to sweep all that ugly stuff under the rug, not deal with it every single time we import a module. The main benefit, the loose coupling that stems from the ability to substitute dependencies without having to change the importing module, can be accomplished in a declarative manner via package managers. Arch Linux packages for example may have a "provides" variable which allows multiple packages to implement an interface of sorts and be used interchangeably to satisfy dependencies. So I think parameterized modules imposed significant costs for little benefit.

matheusmoreira 3y ago

I have! I didn't reflect much on it though because I'm focused on creating a dynamic language. Perhaps I did not understand it? Another interesting concept I ran into while researching modules is parameterized modules. Essentially, modules that take their dependencies as arguments. The modular equivalent to dependency injection I suppose. Instead of a module importing by symbol a specific library as a dependency and some package manager resolving it to actual files in the load path later on, the programmer explicitly loads the library and passes it to the module as an argument. Instead of the symbolic imports we're all used to: (import lib); lib imports lib2 internally Module importing becomes analogous to function calls which construct an instance of the module given its dependencies: (import (lib2)) (import (lib lib2)) This is really elegant and more or less reifies package management into the language. However, it presents serious ergonomics issues because it forces the programmer to deal with all these package management and library loading details. The truth is we want to sweep all that ugly stuff under the rug, not deal with it every single time we import a module. The main benefit, the loose coupling that stems from the ability to substitute dependencies without having to change the importing module, can be accomplished in a declarative manner via package managers. Arch Linux packages for example may have a "provides" variable which allows multiple packages to implement an interface of sorts and be used interchangeably to satisfy dependencies. So I think parameterized modules imposed significant costs for little benefit.