Skip to content

OxCaml: Support for kind annotations#1410

Open
art-w wants to merge 4 commits intoocaml:masterfrom
art-w:oxcaml-layout
Open

OxCaml: Support for kind annotations#1410
art-w wants to merge 4 commits intoocaml:masterfrom
art-w:oxcaml-layout

Conversation

@art-w
Copy link
Copy Markdown
Collaborator

@art-w art-w commented Apr 14, 2026

Builds on top of #1404 (which adds the oxcaml test file)

This PR adds support for OxCaml kind annotations :)

@art-w art-w changed the title Oxcaml layout OxCaml: Support for kind annotations Apr 14, 2026
("recent.mli", Min "5.4");
("labels.mli", Min "4.09");
("recent_impl.ml", Min "4.09");
("recent_impl.ml", MinNotOxCaml "4.09");
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

recent_impl.ml is the only .ml file currently tested, and it uses simple type t = A which in OxCaml now renders as type t : immediate = A (which is correct, but not compatible with the OCaml output). I tried to "complexify" the type definition, but then you either get immutable_data or mutable_data instead so that doesn't help! :P

(This doesn't seem to be an issue for .mli testing, because OxCaml doesn't try to infer more precise kinds than the ones specified)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

That seems fine to me. OxCaml not being run on this specific test seems fine. Adding the variant MinNotOxCaml is fine.

Just to confirm I understand correctly:

type t = A

will be loaded as different values in odoc, depending on whether they are in an ml or mli file:

  • In an ml file, some layout is inferred for t, from the definition, and stored in the cmt
  • In an mli file, nothing is inferred and the Default annotation is loaded from the cmi.

This seems strange, and will discourage the use of ml without mli, since it will be impossible to have a type without an annotation!
But if it comes from the cmti, I'm not sure we should do anything about that.

@art-w art-w marked this pull request as draft April 14, 2026 12:48
@art-w art-w force-pushed the oxcaml-layout branch 2 times, most recently from 8cfaec2 to 50e0a0b Compare April 15, 2026 15:30
@art-w art-w marked this pull request as ready for review April 15, 2026 15:40
Copy link
Copy Markdown
Collaborator

@panglesd panglesd left a comment

Choose a reason for hiding this comment

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

Looks good to me!

The only improvements I see is to have test the kind products (eg, bit32 & float64). In particular, do we need to use parentheses for thing like (bit32 mod portable) & (float64 mod contended)?

I am also not sure what Pjk_kind_of represents, and whether it is tested or not...

Comment thread src/document/generator.ml
Comment on lines +433 to +455
and kind_annotation (k : Odoc_model.Lang.KindAnnotation.t) =
match k with
| Default -> O.noop
| Abbreviation s -> O.txt s
| Mod (base, modes) ->
kind_annotation base ++ O.txt " " ++ O.keyword "mod"
++ O.txt (" " ^ String.concat ~sep:" " modes)
| With (base, ty, modalities) -> (
kind_annotation base ++ O.txt " " ++ O.keyword "with" ++ O.txt " "
++ type_expr ty
++
match modalities with
| [] -> O.noop
| mods ->
O.txt " " ++ O.keyword "mod"
++ O.txt (" " ^ String.concat ~sep:" " mods))
| Kind_of ty -> O.keyword "kind_of_" ++ O.txt " " ++ type_expr ty
| Product ks -> O.list ks ~sep:(O.txt " & ") ~f:kind_annotation

and with_kind_annotation kind base =
match kind with
| Odoc_model.Lang.KindAnnotation.Default -> base
| k -> O.txt "(" ++ base ++ O.txt " : " ++ kind_annotation k ++ O.txt ")"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Probably it would make sense here to add some boxes and break hints. I don't know how pervasive are the multiplicity of kinds.

For comparison, oxcamlformat turns

type t : global aliased many contended portable forkable unyielding immutable stateless external_

into

type t :
  value
  mod
     aliased
     contended
     external_
     forkable
     global
     immutable
     many
     portable
     stateless
     unyielding

and it turns

type t : value mod global aliased many contended portable forkable unyielding immutable stateless external_ & value mod global aliased many contended portable forkable unyielding immutable stateless external_

into

type t :
  ((value
     mod
        aliased
        contended
        external_
        forkable
        global
        immutable
        many
        portable
        stateless
        unyielding)
   & value)
  mod
     aliased
     contended
     external_
     forkable
     global
     immutable
     many
     portable
     stateless
     unyielding

(which shows also that parenthesis are needed, as this is different from:

type t : (value mod global aliased many contended portable forkable unyielding immutable stateless external_) & (value mod global aliased many contended portable forkable unyielding immutable stateless external_)

which is formatted as

type t :
  (value
    mod
       aliased
       contended
       external_
       forkable
       global
       immutable
       many
       portable
       stateless
       unyielding)
  & (value
      mod
         aliased
         contended
         external_
         forkable
         global
         immutable
         many
         portable
         stateless
         unyielding)

)

Could you include those tests first? And then we decide if we need to fix the formatting in this PR.

Comment thread src/document/generator.ml
match modalities with
| [] -> O.noop
| mods ->
O.txt " " ++ O.keyword "mod"
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.

Drive by comment: I think this should be @@ rather than mod. See this page for a grammar for the syntax.

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.

3 participants