Hi, I don’t understand how the toplevel chooses which module alias to use when displaying types. Consider the following example:
file common.ml:
type t = { data : string }
file a.ml:
open Common
let make s = { data = s }
file my_lib.ml
module Common = Common
module A = A
file dune:
(library
(name my_lib))
Then I compile with dune build, and open dune utop:
─( 11:27:31 )─< command 0 >───────────────────────────────────────────────────────{ counter: 0 }─
utop # open My_lib;;
─( 11:27:32 )─< command 1 >───────────────────────────────────────────────────────{ counter: 0 }─
utop # let x = A.make "hello";;
val x : Common.t = {My_lib__.Common.data = "hello"}
─( 11:27:43 )─< command 2 >───────────────────────────────────────────────────────{ counter: 0 }─
utop # let y : Common.t = A.make "hello";;
val y : Common.t = {My_lib.Common.data = "hello"}
─( 11:27:47 )─< command 3 >───────────────────────────────────────────────────────{ counter: 0 }─
utop # x = y;;
- : bool = true
I would rather have the toplevel choose the “y” case above by default instead of “x” which seems inconsistent to me: Common.t and My_lib__.Common.data are used on the same line. Similary, one gets:
utop # let z : My_lib__.Common.t = A.make "hello";;
val z : Common.t = {My_lib__.Common.data = "hello"}
Luckily, everything is compatible:
utop # x=y, x=z;;
- : bool * bool = (true, true)
so that’s not an issue when programming, but having utop display the “hidden” module is annoying. What is the rationale behind this?
This seems to contradict the philosophy of the manual:
Note the use of double underscores in Mylib__A and Mylib__B. These were chosen on purpose; the compiler uses the following heuristic when printing paths: given a path Lib__fooBar, if Lib.FooBar exists and is an alias for Lib__fooBar, then the compiler will always display Lib.FooBar instead of Lib__fooBar. This way the long Mylib__ names stay hidden and all the user sees is the nicer dot names. This is how the OCaml standard library is compiled.
1 post - 1 participant