Hi, would I be right to conclude that polymorphic types in OCaml would not have been needed if modules were better integrated in the language? E.g. taking OCaml as it is now it is possible to code without using polymorphic types and yet retain the full expressive power of OCaml and the only down…

You cannot write the following function with monomorphic functor currently: type 'a t = | Elt of 'a | List of 'a list t let rec list: 'a. 'a t -> 'a list = function | Elt x -> [x] | List l -> List.concat (list l) since the corresponding recursive functor is unsafe: module Listify(T: sig …

Can you give an example of what you mean by ‘if modules were better integrated in the language’? Polymorphism is all about generalising code so it has more utility. I don’t think OCaml would be very expressive without it at all. Even operators such as (|>) rely on polymorphism to work, i.e. it has …

[image] lepoetemaudit: Polymorphism is all about generalising code so it has more utility. I don’t think OCaml would be very expressive without it at all. Even operators such as (|>) rely on polymorphism to work Hi, but you can write something like this right? module type SINGULART = sig typ…

Ah okay, now I see what you mean. That’s interesting - perhaps ultra lightweight functors could be a viable way of doing things, and everything is monomorphic at use. I wonder if it wouldn’t feel a bit like macros or templates in other statically typed languages.

If everything is monomorphic that would be like C++ or Rust and probably blow up compile times and executable sizes.

[image] lepoetemaudit: … and everything is monomorphic at use. I wonder if it wouldn’t feel a bit like macros or templates in other statically typed languages [image] yawaramin: If everything is monomorphic that would be like C++ or Rust and probably blow up compile times and executable s…

[image] atagunov: Loosing inference obviously is not a goal But preserving type interference for the simpler core language is one of the aim of the separation between the module and core type systems. [image] atagunov: Thanks a lot, I didn’t realize functors yield monomorphic code. Th…

[image] octachron: since the corresponding recursive functor is unsafe: Slightly orthogonal note, but it’s not really “unsafe”, merely not handled by the recursive module compilation. Roughly speaking, it’s fairly trivial (and correct) to mark functors as always safe, but the drawback is that…

For reference: the following paper describes the translation of SML to an internal language (comprising a core language and a module language), where SML let-polymorphism is translated to functors. Chris Stone and Robert Harper. A Type-Theoretic Interpretation of Standard ML. Milner Festschrifft.…

[image] atagunov: I didn’t realize functors yield monomorphic code [image] octachron: One could avoid this issue by specializing functors applications on module with only type components …wouldn’t compiling a module to a vtable, C++ style, allow to compile functors polymorphically in …

No? You would have the same issue that in C++ with a separate vtable for each instance of a template class. Typically, C++ cannot handle polymorphic recursion at all. Trying to compile, the C++ version of the list function above is quite “fun”.

Who needs polymorphics types? (when we have modules)

Learning

smolkaj April 21, 2021, 4:25am 16

Oops, I missed that.

Topic		Replies	Views
Modular Implicits Ecosystem compiler , faq	63	24376	October 24, 2022
Ad hoc polymorphism and usability Ecosystem	50	5933	January 14, 2022
Inline module expr Ecosystem compiler	15	1806	November 4, 2020
Polymorphism in OCAML Learning polymorphism	7	834	July 12, 2024
Nested functors: Compiler can't determine type equality Learning functor	20	433	March 12, 2026

Who needs polymorphics types? (when we have modules)

Related topics