Re: [Caml-list] Applicative Functor Madness

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

On 2018/09/21 10:25, Arlen Cox wrote:
> 
> Are the actual rules of module equality documented somewhere in the OCaml manual?

It seems you found them. Unfortunately, the OCaml manual does not provide a formal specification of OCaml, and it sometimes omits some implementation details. In this case I think it suffices.

> It seems like Section 8.12 documents this (at least partially):
> 
> There are several restrictions on module-path:
>   1. it should be of the form M0.M1...Mn (i.e. without functor applications);
>   2. inside the body of a functor, M0 should not be one of the functor parameters;
>   3. inside a recursive module definition, M0 should not be one of the recursively defined modules.
> 
> Obviously in doing this inside a functor, I violated rule #2.

Indeed

>  What I don't understand is if there are clear syntactic rules, should there not be at least a warning when the rules are violated?

The problem is that module aliases were only introduced recently, and reuse the syntax for module definitions.
While “module M = Arg” in a module is not typed as a module alias, it is still a module definition, and as such there is no reason to warn. (But you have a point that at least optionally warning about this could be a good idea.)
Another reason is that originally module aliases were introduced as an optimization to allow referring to other compilation units without including their whole type in the cmi. This is used in 4.07 to provide a Stdlib module, which contains just pointers to the modules of the standard library. From that point of view, it seemed reasonable to keep the same syntax.

>  Second, how does your solution not still violate rule #1?

Because it doesn’t use a module alias, but a destructive substitution.
A destructive substitution substitutes a module path for a path in the signature, removing this path.
Since it removes it, it doesn’t create an alias, and there is no need for restricting the form of the substituted path.
There are other restrictions on where this path is allowed to appear, and some signatures just cannot be inhabited, though.

Jacques Garrigue

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs