4 ms·

I know this is an unpopular position in the OCaml ecosystem, but I find .mli files to be in all ways inferior to the "inline" approach Rust (amongst others) tak

I know this is an unpopular position in the OCaml ecosystem, but I find .mli files to be in all ways inferior to the "inline" approach Rust (amongst others) take. OCaml requires perpetual context switches between .ml and .mli files, which can be alleviated with proper IDE tools but is still annoying, but most annoyingly requires writing every type definition and module signature twice. On the other hand the OCaml/interface files approach is superior when you want to read documentation w/o implementation, but in practice using odoc is superior because you get hyperlinks. In 10 years of using OCaml, I think everytime I interacted with mli I'd rather the author annotated types at the definition site.

yawaramin 3y ago
That's funny because I feel the opposite. An interface file saves me from having to wade through the implementation details and lets me focus on the exact parts that are relevant to me as a reader of the code. And yes odoc is nice too but the source of its usefulness usually comes from the fact that it's generated from a carefully curated interface file.
- eviks 3y ago
  Would type "dehints" be the best of both worlds: you IDE could hide all the types (just like with type hints it adds them) and you could toggle them to eg hide when reading the code? But then also you could toggle them back when needed instead of having to open an interface file?
  - rwmj 3y ago
    OCaml IDEs including emacs can do that already, and yes it's a good thing.
  - deredede 3y ago
    In my opinion the best of both worlds would just be to have Rust-style inline annotations and an "interface mode" that hides implementations (most modern IDEs can already do that) and non-public function. BTW I am not sure why you would want to hide the types, I find them always useful.
- deredede 3y ago
  I agree that the usefulness of documentation systems such as odoc comes from a carefully curated interface, but I disagree with them needing a separate file which in my experience is cause of friction. Other languages (I am familiar with Rust and Python) also have documentation systems that only show you public methods (and functions, types, etc.), and I find them equally useful as odoc. They just take the visibility information from inline annotations (which are enforced by the compiler, in the case of Rust) instead of a separate file.
delta_p_delta_x 3y ago
> I find .mli files to be in all ways inferior to the "inline" approach Rust (amongst others) take Agreed. The same criticism can be levelled at C and C++ with header and implementation files.

yawaramin 3y ago

That's funny because I feel the opposite. An interface file saves me from having to wade through the implementation details and lets me focus on the exact parts that are relevant to me as a reader of the code. And yes odoc is nice too but the source of its usefulness usually comes from the fact that it's generated from a carefully curated interface file.

eviks 3y ago
Would type "dehints" be the best of both worlds: you IDE could hide all the types (just like with type hints it adds them) and you could toggle them to eg hide when reading the code? But then also you could toggle them back when needed instead of having to open an interface file?
- rwmj 3y ago
  OCaml IDEs including emacs can do that already, and yes it's a good thing.
- deredede 3y ago
  In my opinion the best of both worlds would just be to have Rust-style inline annotations and an "interface mode" that hides implementations (most modern IDEs can already do that) and non-public function. BTW I am not sure why you would want to hide the types, I find them always useful.
deredede 3y ago
I agree that the usefulness of documentation systems such as odoc comes from a carefully curated interface, but I disagree with them needing a separate file which in my experience is cause of friction. Other languages (I am familiar with Rust and Python) also have documentation systems that only show you public methods (and functions, types, etc.), and I find them equally useful as odoc. They just take the visibility information from inline annotations (which are enforced by the compiler, in the case of Rust) instead of a separate file.

delta_p_delta_x 3y ago

> I find .mli files to be in all ways inferior to the "inline" approach Rust (amongst others) take Agreed. The same criticism can be levelled at C and C++ with header and implementation files.