Syntax questions around explicit and implicit module applications

I am working on Modular implicits, an experimental OCaml feature that is intended as a typeclass-like mechanism. The idea behind it is to have an implicit argument mechanism with module arguments. There remain important unsolved design questions around modular implicits and we don't expect them to be integrated in the language before at least a few years.

It has been suggested in the past to integrate modular explicits first, which permits writing module dependent functions without providing any implicit inference or elaboration. I believe that this is a nice idea, and am preparing a new PR to propose modular explicits for integration in the next few weeks/months.

There are thorny questions around the syntax we want for those features. We plan to propose only modular explicits at first, but we want to pick a syntax that integrates well with the language today, but will also integrate well with modular implicits proposed in the future.

In this post we propose to discuss the syntax for both (and related OCaml features) to have a better view of the (syntactic) design space. It presents 4 different syntaxes that I have heard about for modular explicits/implicits (the 4th being my favorite but the most complicated).

Proposal by Matthew Ryan

The first PR for modular explicits by M. Ryan proposed to reuse the syntax of modular implicits presented above for modular explicits: let f {M : S} x ... for explicit module abstractions, and f {Int} foo for explicit module applications.

The idea is that if we add modular implicits later, then all examples can be re-intepreted as modular implicits, and now providing explicit applications is optional -- explicit applications f {Int} foo are still supported, but users can write just f foo and the module arguments gets (implicitly) elaborated.

Problem: split between first-class modules and dependent module arguments

The main issue with this proposal is the split between first-class modules and dependent module arguments. The two features are very related (a function can take a module as parameter), but they have different syntaxes and different typing rules:

• let f (module M : S) = body can receive any first-class module as argument, however M cannot appear in the type of body
• let f {M : S} = body must receive a module expression at application, but M can appear in the type of body

How will non-expert users know which one to use ?

This problem was spotted by @EduardoRFS (see github or discuss).

• On one hand we have first-class modules that are known by the community, they are a regular type of value but cannot be made dependent.

• On the other hand there are modular explicits with a completely different syntax that will be brand new. It is not a value thus we cannot have a function that returns a module using this mechanism, but functions can be made dependent.

Ideally we could use a syntax for modular explicits that coincides with first-class modules, at least in the cases where both can be used, and yet integrates gracefully with modular implicits.

In order to think and discuss about this problem we will present and give arguments for and against various syntaxes for modular implicits and explicits.

1 - The initial proposal for modular implicits

In 2014 Leo White, Frédéric Bour and Jeremy Yallop proposed a syntax with brackets for implicit arguments :

module type Show = sig
    type t
    val show : t -> string
end

let show {S : Show} x = S.show x
(* val show : {S : Show} -> S.t -> string *)

let () =
    print_string (show 3);
    print_string (show {Variant_Int_Show} 3)

Pros of this syntax :

• This syntax allows a compact syntax for implicit arguments that might be frequent.
• There is a clear distinction between implicit arguments and regular arguments.

Cons of this syntax :

• We have this unergonomic split between first-class modules and modular implicits.
• At the call-site the user decides to provide an explicit module argument or not, but at the function-declaration site it is not possible to force all call-sites to explicitly provide an argument, which is sometimes desired for readability or for functions that cannot be inferred implicitly.
• If we have 3 implicits argument, and we want to instantiate the third by hand, we need to instantiate the other two.

2 - New proposal : Modular implicits as optional modular explicits

The idea here would be to use the syntax presented above for modular explicits as done by Matthew Ryan, but with labels to module arguments.

(** always applied explicitly *)
let f1 {M : S} = body1

(** always applied explicitly but named *)
let f2 ~named_module:{M : S} = body2

(** can be applied implicitly or explicitly *)
let f3 ?implicit_module:{M : S} = body3

The idea being : if a module argument has an implicit label and is omitted we use the implicit inference mechanism to infer the module expression.

Pros:

• A compact syntax for modular explicits and implicits.
• We are able to easily switch between implicit and explicit module arguments.
• If we have 3 implicits argument, and we want to instantiate the third by hand, we can by giving its label.

Cons:

• First class modules still cannot be used to write module dependent functions.
• We reuse the ? symbol with a slightly different semantic (but we could choose a different symbol).
• All implicit arguments need 2 names (module name + label name) because both use a different set of namespace (but maybe ~M, ?M could be allowed?).

3 - Removing the split: unioning first-class modules and dependent module arguments

The idea of this syntax would be to allow functions taking an argument that is an unpacking of a first-class module to be dependent.

For example :

module type Show = sig
    type t
    val show : t -> string
end

let show_explicit (module S : Show) x = S.show x
(* val show_explicit : (module S : Show) -> S.t -> string *)

let () = print_string (show (module Show_Int) 3)

For implicit abstractions we could use the implicit keyword:

let show (implicit S : Show) x = S.show x
(* val show : (implicit S : Show) -> S.t -> string *)

let () =
    print_string (show 3);
    print_string (show (implicit Variant_Int_Show) 3)

Pros :

• Users will not have to choose if their functions use first-class modules or modular explicits as it is the same syntax for both.
• We can use the label mechanism with modular explicits (same as the syntax above)

Cons :

• Modular explicit and implicits becomes as verbose as first-class modules (use of the module/implicit keyword everywhere)

4 - New proposal : Both (2 + 3)

The idea here would be to have a mix of syntax 2 and 3 presented above. To put it simply all the examples above up to the implicit keyword would be accepted :

• functions taking a first-class module as argument can be made dependent,
• and modular explicits can be written with braces ({M : S}) (with labels for implicits).

module type Show = sig
    type t
    val show : t -> string
end

(** We can write module dependent functions with both syntax *)

let show_explicit (module S : Show) x = S.show x
(* val show_explicit : (module S : Show) -> S.t -> string *)

let show_explicit2 {S : Show} x = S.show x
(* val show_explicit2 : {S : Show} -> S.t -> string *)

(** Coercion is possible between them *)
let show_explicit3 = (show_explicit2 :> (module S : Show) -> S.t -> string)

(* Modular implicits use optional labels *)
let show {S : Show} x = S.show x

This would lead to 2 different incompatible syntax for passing module arguments to module-dependent functions. However, one would be strictly less expressive than the other but also the less verbose.

Pros :

• First-class modules can be dependent, and we have a compact syntax available for modular implicits,
• We are able to easily rewrite a function between implicit and explicit module arguments
• If we have 3 implicits argument, and we want to instantiate the third by hand, we can by giving its label.

Cons :

• We reuse the ? symbol with a slightly different semantic (but we could choose a different symbol)
• All implicit arguments need 2 names (module name + label name) because both use a different set of namespace (but could be changed).

Other possible extensions

When discussing syntax of modular explicits and modular implicits, syntax of other features could also be brought to your attention.

(Semi-)Explicit type arguments

It could be useful for readability to be able to give a type argument to a function. Using modular explicits we will be able to give a module containing exactly a type to a dependent function but not directly the type.

A way to solve this could be to reuse the syntax for modular implicits presented above with braces or labels + braces and use this for type arguments :

let id {type a} (x : a) = x
(* val id : {type a} -> a -> a*)

let result (id : {type a} -> a -> a) = (id 3, id {type bool} true)

Such a mechanism would be a way to receive polymorphic arguments when writing a function.

We could also offer this with the implicit keyword or with labelled arguments:

let id (implicit type a) (x : a) = x
(* val id : (implicit type a) -> a -> a*)

let id ?a:(type a) (x : a) = x
(* val id : ?a:(type a) -> a -> a *)

Signatures parametrized over a type

With modular implicits/explicits we could need to write a function demanding multiple modules with the same type.

let compute {E : Eq}
    {A : Add with type t = E.t}
    {S : Sub with type t = E.t}
    {D : Default with type t = E.t} () = ...

However, this can become pretty verbose. A fix for this would be to allow parametric signatures because we know that those signatures will (almost) always be used with a with type t = ....

This would allow us to write a much more compact code.

let compute {E : Eq} {A : Add(E.t)} {S : Sub(E.t)} {D : Default(E.t)} () = ...

However, this poses a few questions :

• Should we write Add(E.t) or maybe Add(type E.t) or E.t Add ?
• How should we write the definition of a parametric signature ?
  module Eq (type t) = type val eq : t -> t -> bool end?
  module type t Eq = type val eq : t -> t -> bool end?
• Should we always write the parameter of the parametric signature ? Or can it be inferred or abstracted when not written ?