3 ms·

Someone mind explaining how these help? I'm unfamiliar with OCaml, but looking at the documentation of modules, I don't understand what they have to do with int

Someone mind explaining how these help? I'm unfamiliar with OCaml, but looking at the documentation of modules, I don't understand what they have to do with interfaces in the OOP sense(EDIT: or, rather, ad-hoc polymorphism), which I'm pretty sure is what the author meant.

Errancer 3y ago
The point as I understand is that interfaces in the OOP sense try to mimic what modules do. Therefore OCaml not having them is not a serious accusation since everything you try to accomplish with interfaces / design patters you can and should be able to do with modules. Here is the article explaining the concept: https://www.pathsensitive.com/2023/03/modules-matter-most-for-masses.html https://www.pathsensitive.com/2023/03/modules-matter-most-fo... but I have to note that I never worked in OCaml so this is just my theoretical understanding.
Verdex 3y ago
To be fair, ocaml doesn't have something exactly like c#/java interfaces. Given some problem that you might want to solve with a c#/java interface, you can also solve it with ocaml modules by flipping the coding structure on it's head. I'm not going to try to explain exactly what this looks like because I actually don't really like that structure of coding, so I don't feel like I'm going to do it justice. BUT ocaml also has row polymorphism and polymorphic invariants, which you can use to get something much directly closer to c#/java interfaces. The major difference is that with ocaml it's structural typing and with c#/java it's nominal typing. However, at a high level you can write the code in a very similar structural pattern as with what you get in c#/java.
WastingMyTime89 3y ago
> I'm pretty sure is what the author meant. Clearly not considering he mentions typeclass in the article. Module signatures are similar to interface and parametrized modules allow you to do what you would do with abstract class: you define a signature and then write a module using these functions. Parametrized modules are more or less a generalization of functions which goes from module to module.
- arc-in-space 3y ago
  Sorry, I initially wrote 'interfaces as in OOP' to distinguish them from module interfaces, but had 'ad-hoc polymorphism' in mind. 'interfaces' is much too overloaded of a term.
  - WastingMyTime89 3y ago
    Ocaml has no ad-hoc polymorphism but you can use parametrised modules to write generic code which you will have to specialise at some point. That brings you ninety percents of the way in term of what ad-hoc polymorphism is used for. It's more cumbersome but I prefer it to the complexity involved by what Scala does for exemple.
    - ywei3410 3y ago
      Would you not consider the object system to be ad-hoc polymorphism?
      - octachron 3y ago
        The OCaml object system is still parametric polymorphism (trying to pass itself as subtyping polymorphism through row variables) rather than ad-hoc polymorphism: there are still no functions that only work on a finite subset of types. In other words, a function may work on any objects that has a method `m`, but you cannot have the same method that has different implementation for `int` and `float`.
      - WastingMyTime89 3y ago
        It uses structural typing not ad-hoc polymorphism. Plus it’s rarely used and it used to give hard to parse error messages when you made type mistakes. I don’t really see it as an adequate replacement for ad-hoc polymorphism.

Errancer 3y ago

The point as I understand is that interfaces in the OOP sense try to mimic what modules do. Therefore OCaml not having them is not a serious accusation since everything you try to accomplish with interfaces / design patters you can and should be able to do with modules. Here is the article explaining the concept: https://www.pathsensitive.com/2023/03/modules-matter-most-for-masses.html https://www.pathsensitive.com/2023/03/modules-matter-most-fo... but I have to note that I never worked in OCaml so this is just my theoretical understanding.

Verdex 3y ago

To be fair, ocaml doesn't have something exactly like c#/java interfaces. Given some problem that you might want to solve with a c#/java interface, you can also solve it with ocaml modules by flipping the coding structure on it's head. I'm not going to try to explain exactly what this looks like because I actually don't really like that structure of coding, so I don't feel like I'm going to do it justice. BUT ocaml also has row polymorphism and polymorphic invariants, which you can use to get something much directly closer to c#/java interfaces. The major difference is that with ocaml it's structural typing and with c#/java it's nominal typing. However, at a high level you can write the code in a very similar structural pattern as with what you get in c#/java.

WastingMyTime89 3y ago

> I'm pretty sure is what the author meant. Clearly not considering he mentions typeclass in the article. Module signatures are similar to interface and parametrized modules allow you to do what you would do with abstract class: you define a signature and then write a module using these functions. Parametrized modules are more or less a generalization of functions which goes from module to module.

arc-in-space 3y ago
Sorry, I initially wrote 'interfaces as in OOP' to distinguish them from module interfaces, but had 'ad-hoc polymorphism' in mind. 'interfaces' is much too overloaded of a term.
- WastingMyTime89 3y ago
  Ocaml has no ad-hoc polymorphism but you can use parametrised modules to write generic code which you will have to specialise at some point. That brings you ninety percents of the way in term of what ad-hoc polymorphism is used for. It's more cumbersome but I prefer it to the complexity involved by what Scala does for exemple.
  - ywei3410 3y ago
    Would you not consider the object system to be ad-hoc polymorphism?
    - octachron 3y ago
      The OCaml object system is still parametric polymorphism (trying to pass itself as subtyping polymorphism through row variables) rather than ad-hoc polymorphism: there are still no functions that only work on a finite subset of types. In other words, a function may work on any objects that has a method `m`, but you cannot have the same method that has different implementation for `int` and `float`.
    - WastingMyTime89 3y ago
      It uses structural typing not ad-hoc polymorphism. Plus it’s rarely used and it used to give hard to parse error messages when you made type mistakes. I don’t really see it as an adequate replacement for ad-hoc polymorphism.