Continuing the discussion from Generic numeric module, Problem with types : [image] Generic numeric module, Problem with types [image] Generic numeric module, Problem with types I generally sometimes wonder how to be forward compatible with includes and open. I solve this by not doing open …

Note that it sounds like you are missing also the use of local module alias: module R = Relation let f { R.lhs; op; rhs } = ... which often offers a good compromise between conciseness and explicitness when a module is very often used in a given module. For your naming issue, I generally define b…

[image] jbe: (* let open M in *) This will bring every record label and constructor defined in M into scope. What exactly did you try? In my experience prefixing record labels and constructors with their module is not too heavy, ie {M.foo = 5}, since 1) you only need to do it for the first l…

[image] nojb: [image] jbe: (* let open M in *) This will bring every record label and constructor defined in M into scope. What exactly did you try? I would like to bring constructors and record fields into scope selectively. Consider: module M = struct type t = { foo : int } le…

The answer is no but to further expand on @nojb ’s answer you can delete your let open M and write: let _ = M.{ foo = 5 } in

The syntax is nice, but comes with a risk: module M = struct type t = { foo : int; bar : bool } let ( = ) a b = a.foo = b.foo end let () = let a = 1 in let b = 2 in let _ = M.{ foo = 5; bar = (a = b) } in () The above example won’t compile, again for the same reason as discussed in t…

[image] jbe: And I’m not sure what’s the best approach. I am tempted to say that the best approach is simply to qualify your record field: {M.foo = 5}. Cheers, Nicolas

Would that mean that exposing concrete types, including type constructors (those with a capital letter in the beginning) and record fields, is likely something to only do where there is some “intimacy” between the library and its user? In that case, one could argue, a user of a module would need to…

[image] octachron: Note that you also selectively re-export a type type 'a relation = 'a Relation.t = { lhs : 'a array; mutable op: comp_op; mutable rhs:'a } Oh, so I could do this: module M = struct type t = { foo : int } let z = "zero" end type t = int let () = let z : t = 5 in …

For selectively importing types you may consider ppx_import type%import relation = Relation.t

Idiomatically I would do this: module M = struct type t = { foo : int } end let () = let z = 5 in let x = { M.foo = z } in assert (x.foo = z)

Selectively bringing constructors or record fields into scope

Learning

dbuenzli February 17, 2026, 1:44pm 7

Or make your type abstract and provide a constructor and accessors for it.

When to use iarray instead of array?

Topic		Replies	Views
Concise Module Syntax Community language-design , ideas	23	4608	January 5, 2018
Why does the order of fields in a record type definition matter? Learning	33	775	February 17, 2025
Extend existing module Learning ocaml , module	19	7985	January 31, 2018
When do I need to prefix constructors with the module name? Learning module	4	611	May 2, 2023
Extending `open` to accept arbitrary module expression Community compiler	3	944	December 9, 2017

Selectively bringing constructors or record fields into scope

Related topics