I have added a patch for https://github.com/ocamllabs/compiler-hacking/wiki/Things-to-work-on#wiki-improve-functor-syntax-1

And also for https://github.com/ocamllabs/compiler-hacking/wiki/Things-to-work-on#wiki-improve-functor-syntax-2 it appears

Right, I'm done with this one. Basically, I've added:

(* Optional naming of paramater implementation *)
module type X = functor (X:S) -> ...
module type X = functor (_:S) -> ...
module type X = functor S -> ...

(* shortening of functor modules *)
module F = functor (X:S) -> functor (Y:S) -> ...
module F = functor (X:S) (Y:S) -> ...

(* shortening of functor module signatures *)
module type F = functor (X:S) -> functor (Y:S) -> ...
module type F = functor (X:S) (Y:S) -> ...

The type pretty-printer has been updated as well to always display the shortened functor module signatures.

People don't actually write:

module F = functor (X : S) -> functor (Y : T) -> struct end

but:

module F(X : S)(Y : T) = struct end

The new syntax would only be useful to pass an anonymous functor to a higher-order one. But do people actually do that? I suspect one would rather bind the argument to a named functor, and thus use the existing compact syntax anyway.

So I'm not convinced by the need for allowing functor(X : S)(Y : T) -> ... (I'm not strongly against it either).

Alain, I would guess the rationale is rather to improve functor types syntax, and that the functor (implementation) was updated as well to remain consistent -- it wouldn't be very nice to have a short form for module types that isn't available for modules.

My own remark is that I don't like the functor S -> ... short form. It is too close to the functor X -> ... syntax we would have if signatures could somehow be inferred. In a more general setting, it's dangerous to allow shortening λ(_:α). into λα. because this second form starts making sense as soon as you choose a consistent syntax form term and type abstraction.

Yes, indeed, the rationale was to stay consistent with the functor type syntax.

About the functor S -> ...: I agree this can be confusing in its current form. What about making it equivalent to functor (S:S) -> ... (so that you can use S.t in the body) ? This is similar to the shorten record notation that we already have: fun { field } -> ...

I like your refined proposal better, but I think it still stands out by being the only part of your proposal that is controversial (or at least non-obviously-canonical). If I were you, I would remove it for now and hope for a smooth discussion and acceptance of the rest before going there.

2014-02-19 10:44 GMT+01:00 Thomas Gazagnaire [email protected]:

Yes, indeed, the rationale was to stay consistent with the functor type
syntax.

About the functor S -> ...: I agree this can be confusing in its current
form. What about making it equivalent to functor (S:S) -> ... (so that
you can use S.t in the body) ? This is similar to the shorten record
notation that we already have: fun { field } -> ...

In general, "S" is a signature expression (e.g. "sig end"), not just an
identifier, so it wouldn't make sense in the general case.

I'll add my voice to the choir: I'm OK with "functor (X1: S1) (X2: S2) ->
..." but not with the part of your proposal above.

• Xavier Leroy

Right, I've updated my patches to remove the part which was controversial.

I just looked at the patches. Commits 2 and 3 (pretty-printer and tests) are fine.

I'm wary of the use of continuation-passing style in the parser in commit 1. My experience with continuation-passing is that while it originally seems elegant, it's not worth the extra conceptual complexity of higher-order functions; making sure that the functor arguments are returned in the right order becomes non-trivial, while it should be a no-brainer. Could you revert to the idiomatic style used in the rest of the parser, which is to accumulate lists in reverse order, and List.rev them from the main rule?

That's my only reserve with the patch; otherwise I think it's ready for merging.

@gashe: I've modified my patches to satisfy your demands. Couldn't use List.rev because I'm building a tree instead of a list, but I've tried to keep the idiomatic style.

Well, I was right to point out that this part of the code is tricky, as the new version is wrong ^^

I'll fix it.

Committed in trunk (14474).

There's a small anomaly in the merged patch, in that you no longer have to name arguments of functors written out in the long style:

module F = functor (_ : X) -> struct end

but you still have to name arguments of functors written in the compact style:

module F (_ : X) = struct end (* error *)

Something like the following (lightly tested) should fix it:

index f709eb9..65e496d 100644
--- a/parsing/parser.mly
+++ b/parsing/parser.mly
@@ -665,6 +665,8 @@ module_binding_body:
       { mkmod(Pmod_constraint($4, $2)) }
   | LPAREN UIDENT COLON module_type RPAREN module_binding_body
       { mkmod(Pmod_functor(mkrhs $2 2, Some $4, $6)) }
+  | LPAREN UNDERSCORE COLON module_type RPAREN module_binding_body
+      { mkmod(Pmod_functor(mkrhs "_" 2, Some $4, $6)) }
   | LPAREN RPAREN module_binding_body
       { mkmod(Pmod_functor(mkrhs "()" 1, None, $3)) }
 ;

That's a good point, thanks for throwing more eyeballs. If possible, I'd try to avoid duplicating the underscore-handling logic.

Good idea, @gasche. Here's a patch that refactors the grammar to eliminate duplication in the functor parameter productions: yallop@7685421

Merged in trunk, thanks.