Skip to content

include functor support for OxCaml - #1452

Open
Leonidas-from-XIV wants to merge 13 commits into
ocaml:masterfrom
Leonidas-from-XIV:include-functor
Open

include functor support for OxCaml#1452
Leonidas-from-XIV wants to merge 13 commits into
ocaml:masterfrom
Leonidas-from-XIV:include-functor

Conversation

@Leonidas-from-XIV

Copy link
Copy Markdown
Member

This PR is a follow up to #1368 and adds support for include functor where it now displays that the items were included via the functor.

@Leonidas-from-XIV
Leonidas-from-XIV force-pushed the include-functor branch 3 times, most recently from 18499bf to ca9079a Compare July 1, 2026 08:28
@Leonidas-from-XIV
Leonidas-from-XIV marked this pull request as ready for review July 1, 2026 12:22

@art-w art-w left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot, this looks great! I only have minor feedback but nothing blocking :)

Comment thread src/xref2/tools.ml Outdated
Comment thread src/document/generator.ml Outdated
(** This is a Module where the type is named and then included. *)
module type Make = (_ : sig type t end) -> sig type included end
type t
include functor Make

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, can we test the behavior with (** @inline *)?

@jonludlam

Copy link
Copy Markdown
Member

I think there's a chunk of logic missing from this PR. At the moment, all it does AFAICT is get the expansion of the functor and splice it into the expansion of the include. While this works for simple examples, it's not sufficient for more involved cases.

As a simple example, consider this:

module F ( I : sig type t end ) = struct
  type myt = I.t
end

module M = struct
  type t = float
  include functor F
end

Running this through ocamlc -c -i gives what we ought to end up with (roughly):

module F : functor (I : sig type t end) -> sig type myt = I.t end
module M : sig type t = float type myt = float end

If we just simply get the signature of the functor body and splice it in, we end up something more like:

...
module M : sig
  type t = float
  type myt = I.t
end

and obviously that I.t need something done to it. If you run it through odoc as of this branch, it chokes on exactly this:

Exception Failure("Not_found: I/3") handling type_expr: resolved(I/3.t)
backtrace:
Raised at Stdlib.failwith in file "stdlib.ml" (inlined), line 39, characters 17-33
...

I suspect the most straightforward implementation of this would be to do exactly what the docs suggest it does internally. Treat it more like:

module M = struct
  module __DUMMY__ = struct
    type t = float
  end

  include __DUMMY__
  include F(__DUMMY__)
end

We can ensure that the dummy module is hidden, meaning that the include will just inline the contents,
so it should end up rendering in a sensible way. I'm not sure whether it would be best to do this as
a preprocessing step or whether we might be able to rewrite the loaders with an accumulator so we can
do this sort of mangling on loading of the cmt/cmtis.

@Leonidas-from-XIV
Leonidas-from-XIV force-pushed the include-functor branch 2 times, most recently from e54c667 to 1dbd45c Compare August 13, 2026 13:04
@Leonidas-from-XIV

Leonidas-from-XIV commented Aug 13, 2026

Copy link
Copy Markdown
Member Author

I've now implemented @jonludlam's proposal of compiling down the include functor to basically a BODY module and a functor application. This has some extra steps to deal with odd cases like anonymous functors but seems to work fine. I've also incorporated the example and it compiles now properly.

The way it works is by parsing the include functor as Include.Functor expression (with a path or module type) and then post-processing the structure items if there were include functors and compiling them to Include.Functor with paths (to be able to use `Apply thus avoiding having to infer types) in the shape of <GENERATED_FUNCTOR_MODULE>(GENERATED_WRAPPER_MODULE>). I'm also retaining the original expression, so the include functor <X> will be rendered as include functor <X> instead of include functor APPLY_23(BODY_12).

However there's one outstanding issue: while the items coming from the functor expansions contain the right path (e.g. val functor_output = APPLY_23(BODY_12).functor_output) this is is quite ugly and messy. If I hide the generated modules the cross-reference disappears and just the value remains. This might be fine but also somewhat less informative.

What I could imagine would be best if I could hide the generated modules but also tell the cross-linker that I want the item to be cross-referenced to the ("include") functor, not the generated module. Is there a way to tell odoc to "redirect" paths?

@Leonidas-from-XIV

Copy link
Copy Markdown
Member Author

Odoc has a mechanism to specify a substitution via @canonical which is represented by the `Canonical constructor, however that can only be constructed with resolved modules, whereas the Typedtree transformation is happening before. Maybe it is possible to resolve these modules early.

@panglesd panglesd left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll continue the review, but here is already some comments. I think the Make functor should be made a little bit more complex, and in particular use its argument.

module Make (T : sig type t end) : sig type included = T.t end

Now suppose it is used in the following way:

type t
include functor Make

From my understanding of the oxcaml feature, the rendered signature should be:

type t
> include functor Make
  type included = t

(where > is for the opened include accordion 🪗 )
In my testing, that is not the case!

I wonder if it is possible to fix that using the current "sugar". I believe the "desugared" form of the example above (extended with a value and a module) could use aliases, for types, modules and module types, instead of relying on the DUMMY__ include :

type t
val f : t
module X : S
module DUMMY__ : sig
    type nonrec t = t
    val f : t
    module X = X
  end

  module STRUCT__Make : Make
  include module type of STRUCT__Make(DUMMY__)
end

What do you think?

Also, definitely we want those generated modules to be hidden. As @jonludlam mentioned, that would turn the "inlining" invisible if we keep it, and odoc would use links to a visible alias.

Also note that while I'd like to investigate the alternate sugar, the current version is better than no support, and as such (I still need more review of course) I would not block the merge on the problem noted above!

@panglesd

Copy link
Copy Markdown
Contributor

I had a go at the "alias desugaring" idea: https://github.com/panglesd/odoc/tree/include-functor-alias-desugaring

It looks a reasonable first solution, I think. Maybe implementing the "include functor expansion" mechanism in odoc would be better, but slightly more invasive...

jonludlam added a commit to jonludlam/odoc that referenced this pull request Aug 26, 2026
The synthetic module standing in for the functor argument held copies of the
preceding items.  Since it is hidden, everything the functor's expansion
inherited from its argument came out as `BODY__n.t` -- a hidden path, which
`Link.type_decl` resolves by looking through it, landing on the copy's own
abstract declaration.  So a functor that used its argument, as
`Comparable.Make` does, lost exactly the part worth documenting.

Alias the items instead: a type's manifest points at the real type, a module
becomes an alias of the real module, a module type a path to it.  `BODY__n.t`
then reduces to the enclosing signature's own `t`, and is rendered and linked
as such.

Class types are not aliased.  A functor can refer to one from its argument, but
odoc does not chase class type aliases the way it chases type manifests, so
such a reference is still left printing the wrapper's hidden name.  That is a
pre-existing limitation, reachable without `include functor`:

    module Hidden__thing : sig class type ct = object method m : int end end
    type from_class = Hidden__thing.ct

Suggested by @panglesd in ocaml#1452.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jonludlam added a commit to jonludlam/odoc that referenced this pull request Aug 26, 2026
Rather than put the functor arguments in a module and `include` it,
leave them where they were and construct a synthetic module that's
just full of aliases to the items.

Suggested by @panglesd in ocaml#1452.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants