Comment author: @alainfrisch

I agree it would be very nice to have generative functors in addition to transparent ones. But why should this notion require a "dummy" argument? It is quite common to have functors taking a non-trivial argument, which should be generative (typical example: a hash-consing functor). I'd rather have a different kind of functors (unfortunately, this requires more innovation on the syntactic side than your proposal).

Also, generative functors enable something very useful: unpacking of first-class modules within/as the functor body. This can be used, for instance, to choose at runtime between two implementations of the functor, based on some condition. With runtime types (or a manual version based on GADTs), it is even possible to customize the functor's behavior according to the structure of the abstract types in the argument (example: implement sets as Patricia trees if the elements are integers).

Would your proposal make this possible for generator functors?

Comment author: @garrigue

The idea of using a "dummy" argument is that it requires no new syntax (or very little).
And it is just as expressive: you just have to add () as last argument to make your functor generative.

The discussion should rather be: since generativeness is a property of functors, is it useful to mark it in functor applications. I believe that this is the case, as this is the application, not the functor, that behaves differently.

I have also updated the patch so that it is now possible to unpack first class modules inside impure functors:

module type S = sig val x : int end;;
let v = (module struct let x = 3 end : S);;
module F() = (val v);;

Comment author: @garrigue

Fixed the patch: if we are to allow unpacking inside impure functors, then we should not allow applying them inside an applicative body...

Comment author: @garrigue

Fixed the patch again: one cannot coerce an impure functor into an applicative one.
The patch is in trunk/experimental/garrigue/impure-functors.diff

Comment author: @alainfrisch

FWIW, I believe that extending the language with generative functors would indeed be very useful, especially if it allows to unpack first-class modules in their body.

Comment author: @alainfrisch

Now that 4.01 is branched, what about including the patch in the trunk? It seems nobody objects to it, and there are at least two supporters.

Comment author: @alainfrisch

Jacques: do you think your patch is ready for inclusion, or are you aware of some problems with it?

Comment author: @garrigue

I don't recall any problem, but of course I would check everything again before inclusion.
Some parts may have to be discussed, since I tried to be the less intrusive as possible.

Comment author: @lpw25

An example that should be prevented:

module F () : sig type t end = struct module M = (val ...) type t = M.t end

module G (X : struct end) : sig type t end = struct
module L = F ()
type t = L.t
end

module N1 = G(X)
module N2 = G(X)

where ... is some first-class module expression.

This would have N1.t equal to N2.t even though they may be different types (because they come from unpacking a first-class module).

Comment author: @garrigue

This is already taken care of:

module type S = sig val x : int end
let v = (module struct let x = 3 end : S)
module F() = (val v);;

module G (X : sig end) : S = F ();;

Error: This kind of expression is only allowed inside impure functors.

Comment author: @lpw25

This idea is only half-baked, but I was wondering if the same mechanism could be used to express functors that are only used for their side-effects. Something like:

module F (X : sig ... end) : () = struct
...
do some effectful thing
...
end

module () = F(Foo)

so the functor is given () as its return type, and () can only be given to the module expression (). So the following would be an error:

module M = F(Foo)

similarly, ignoring the result of a normal functor would be an error:

module () = Map.Make(List)

Note that since these side-effect only functors can not create any types, I think they can safely be used within an applicative functor even if they are "impure".

Comment author: @garrigue

I'm not sure we need new syntax for the return type part.
But you're right on one point: if we now that a generative functor returns no types, then it should be safe to call it inside an applicative one.
Same thing applies to unpacking.
Both can be useful in practice.

Comment author: @garrigue

Patch merged to trunk at revision 14365.
It allows opening first class modules and applying generative functors inside applicative functors, if no types are created.