Exotic Programming Ideas: Module Systems
stephendiehl.com
Exotic Programming Ideas: Module Systems
1–10 of 57 posts
Re: Exotic Programming Ideas: Module Systems
#2Great read. It's too bad modules are pretty much an afterthought in most langs.
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).
Re: Exotic Programming Ideas: Module Systems
#3Other 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?
Re: Exotic Programming Ideas: Module Systems
#4Great read. It's too bad modules are pretty much an afterthought in most langs. 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). https://people.mpi-sws.org/~rossberg/1ml/1ml-extended.pdf
Is there a 'readable' code sample of how that would work?
Re: Exotic Programming Ideas: Module Systems
#5> Modules as a language feature were first developed in Modula-2 and Pascal, which were developed as a way to demarcate units of compilation.
Actually Mesa.
Re: Exotic Programming Ideas: Module Systems
#6Other 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?
Module functors and first-class modules are probably the big feature. Those are more akin to allowing functions between classes, rather than just objects.
Re: Exotic Programming Ideas: Module Systems
#7Other 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?
A module, by definition, is a singleton (for parametrized modules, a “once per type” object)
C has (unparametrized) modules, calling them “compilation unit”.
Re: Exotic Programming Ideas: Module Systems
#8Great read. It's too bad modules are pretty much an afterthought in most langs. 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). https://people.mpi-sws.org/~rossberg/1ml/1ml-extended.pdf
Is there a 'readable' code sample of how that would work?
Not much I don't think. This has a few examples:
https://github.com/rossberg/1ml
There isn't special module syntax. Modules are more-or-less just structs, and the structs can contain types.
Re: Exotic Programming Ideas: Module Systems
#9Other 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?
Except where first-class modules are used, the application of a functor to a module happens at at (or before) compile-time. You can have a fully resolved type before runtime, but which can still be abstract at design time. They can be seen as a zero-cost abstraction.
Modules are structurally typed, so the more typical sub-typing behavior expected from mainstream OOP languages is not applicable to them.
Re: Exotic Programming Ideas: Module Systems
#10Other 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?
Module signatures may contain types.
So you can write a signature like:
module type VectorSpace = sig
module Field : Field
type t
val zero : t
val (+) : t * t -> t
val (*) : Field.t * t -> t
end