5 ms·

OCaml: Polymorphism

71 points by haifeng 12y ago

zaphar 12y ago
All of them. But the one I like the most is Parametric polymorphism because it tends to make algorithms generically available to anything. And the one I like the least is subtype polymorphism due to it's reliance on inheritance with all it's attendant problems. The exception being for the sub-genre of "interface" polymorphism. Which doesn't really exist in C++. However when it does exist such as in languages like Go, Java, or C# then it fixes almost all of the problems that tradional subtype polymorphism has by taking inheritance completely out of the picture.
- haifeng 12y ago
  Agree. I like most parametric polymorphism too. The drawbacks are: 1. In C++, the compile error messages with templates are so hard to navigate. 2. In OCaml, sometimes we need pay attentions on the performance.
- ufo 12y ago
  parametric polymorphism also give you "theorems for free" if you choose the right places to put your abstractions.
- panic 12y ago
  OCaml models "interface" polymorphism using an extension to parametric polymorphism called row polymorphism (https://realworldocaml.org/v1/en/html/objects.html https://realworldocaml.org/v1/en/html/objects.html), which lets you avoid subtyping even for interface types.
dougk16 12y ago
Another kind of polymorphism that's way underappreciated is what Qt calls "static polymorphism" (http://doc.qt.digia.com/qq/qq13-apis.html#staticpolymorphism http://doc.qt.digia.com/qq/qq13-apis.html#staticpolymorphism). This is just a fancy word for naming stuff consistently instead of trying to shoehorn constructs to have some kind of formal language-aware relationship via abstract methods, overloaded methods, etc., which sometimes just increases coupling/complexity with no real benefit.
- haifeng 12y ago
  Interesting. It is more a design pattern rather than a language thing. But it is always good to design a consistent API across similar but not related classes.
  - dougk16 12y ago
    Agreed, with all languages I'm aware of this is purely a design concern, outside the scope of language specification. However I'm currently working on a library that relies heavily on this so-called static polymorphism, so you can imagine what a pain it is whenever I do a major refactor. Without formal relationships between classes, methods, etc., it's much more of a manual and error-prone process, as far as introducing inconsistencies in the API. This has led me to ponder some language-level (or even just IDE-level) ways to specify loose relationships between disparate constructs that would make such iterative API development easier. No brilliant insights yet though. :)
    - haifeng 12y ago
      Structural subtyping are mostly close to static polymorphism. After all, we just don't like inheritance, not dynamic polymorphism. Besides, interface and trait are not really inheritance although closely related.
- tel 12y ago
  This happens pretty naturally in OCaml actually. It arises from the structural subtyping relationship on module signatures. You don't really shoehorn anything at all...
gnuvince 12y ago
I'm quite happy to see that every week one or two quality OCaml articles are posted on HN and lobste.rs. OCaml doesn't have the general appeal of JavaScript, the innovation factor of Rust, the get-shit-done reputation of Go, but it deserves to be more widely known.
- vezzy-fnord 12y ago
  The Rust language itself has a noticeably heavy ML influence.
  - haifeng 12y ago
    An ML with many C notations :)
  - Chattered 12y ago
    Its first compiler was written in Ocaml.
- agumonkey 12y ago
  It's funny because ml languages are a lot less alien to the mainstream than before. Things people are used to: - `let` keyword (rust, ES6) - pattern matching (generalization of ES6 destructuring) - function first, HOF combinators (ES5 functional literature) - tuples (python) A few years back, all these would appear as black magic...
  - amirmc 12y ago
    You might find the intro to Real World OCaml interesting as these ideas have percolated out from languages such as OCaml. It's great if that helps lower the barrier for people to try it out. https://realworldocaml.org/v1/en/html/prologue.html#why-ocaml https://realworldocaml.org/v1/en/html/prologue.html#why-ocam...
- haifeng 12y ago
  Thanks for bring Rust into the topic. I know that it is very new. But still wonder if some real life projects are using it (except rustc).
amelius 12y ago
It would be cool to see a "layered" language. By this, I mean a language that has no typing at its lowest level, but you can add it as a library on top of the base level. Then you can add stuff like automatic resolution of calls, etc., as another abstraction level. Of course, you could also add other rules instead of typing. For example, you could pepper your programs with arbitrary proofs, etc., and this could be directed by yet another library on top of your program. Perhaps I'm dreaming. But it sounds like useful to me, as there are so many languages that are almost similar, and yet are slightly different in the way they handle typing and things like polymorphism. It would seem to me that those languages could all share a common base.
- haifeng 12y ago
  I am not sure if typing can be added as a library. In terms of typed lambda calculus vs untyped lambda calculus, can we do this way? But the idea of "layered" language is nice. In Scala, many features are not really from language itself, but from libraries.
- rcsorensen 12y ago
  Perl is dynamic enough to support this. See http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/Types.pod http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/... and http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual.pod http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual.... Competing type systems, competing Object systems, and enough internal run-time rewriting to do whatever it is you want. See also http://search.cpan.org/~smueller/Filter-Simple-0.91/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.91/lib/Filt... for a simple rewriting filter, and the Acme namespace for all kinds of fancy experiments.
- ufo 12y ago
  Optionally typed programming languages are still a big research area and we are just now starting to see some of that research go more mainstream, with things such as Typescript. That said, I don't expect to see a language that does all the things you listed at the same time, since type systems are all about tradeoffs between expressivity and complexity and there is an upper bound in how much complexity a programmer can handle. There are also a lot of other tradeoffs that you need to think about: do unproved assertions get converted to runtime checks or to compile errors? Can you implement that efficiently? How will type inference work? Is it OK to design an unsound type system? etc etc. I can give you some pointers if you want to look for something more specific.

71 points by haifeng 12y ago

All of them. But the one I like the most is Parametric polymorphism because it tends to make algorithms generically available to anything. And the one I like the least is subtype polymorphism due to it's reliance on inheritance with all it's attendant problems. The exception being for the sub-genre of "interface" polymorphism. Which doesn't really exist in C++. However when it does exist such as in languages like Go, Java, or C# then it fixes almost all of the problems that tradional subtype polymorphism has by taking inheritance completely out of the picture.

haifeng 12y ago
Agree. I like most parametric polymorphism too. The drawbacks are: 1. In C++, the compile error messages with templates are so hard to navigate. 2. In OCaml, sometimes we need pay attentions on the performance.
ufo 12y ago
parametric polymorphism also give you "theorems for free" if you choose the right places to put your abstractions.
panic 12y ago
OCaml models "interface" polymorphism using an extension to parametric polymorphism called row polymorphism (https://realworldocaml.org/v1/en/html/objects.html https://realworldocaml.org/v1/en/html/objects.html), which lets you avoid subtyping even for interface types.

dougk16 12y ago

Another kind of polymorphism that's way underappreciated is what Qt calls "static polymorphism" (http://doc.qt.digia.com/qq/qq13-apis.html#staticpolymorphism http://doc.qt.digia.com/qq/qq13-apis.html#staticpolymorphism). This is just a fancy word for naming stuff consistently instead of trying to shoehorn constructs to have some kind of formal language-aware relationship via abstract methods, overloaded methods, etc., which sometimes just increases coupling/complexity with no real benefit.

haifeng 12y ago
Interesting. It is more a design pattern rather than a language thing. But it is always good to design a consistent API across similar but not related classes.
- dougk16 12y ago
  Agreed, with all languages I'm aware of this is purely a design concern, outside the scope of language specification. However I'm currently working on a library that relies heavily on this so-called static polymorphism, so you can imagine what a pain it is whenever I do a major refactor. Without formal relationships between classes, methods, etc., it's much more of a manual and error-prone process, as far as introducing inconsistencies in the API. This has led me to ponder some language-level (or even just IDE-level) ways to specify loose relationships between disparate constructs that would make such iterative API development easier. No brilliant insights yet though. :)
  - haifeng 12y ago
    Structural subtyping are mostly close to static polymorphism. After all, we just don't like inheritance, not dynamic polymorphism. Besides, interface and trait are not really inheritance although closely related.
tel 12y ago
This happens pretty naturally in OCaml actually. It arises from the structural subtyping relationship on module signatures. You don't really shoehorn anything at all...

gnuvince 12y ago

I'm quite happy to see that every week one or two quality OCaml articles are posted on HN and lobste.rs. OCaml doesn't have the general appeal of JavaScript, the innovation factor of Rust, the get-shit-done reputation of Go, but it deserves to be more widely known.

vezzy-fnord 12y ago
The Rust language itself has a noticeably heavy ML influence.
- haifeng 12y ago
  An ML with many C notations :)
- Chattered 12y ago
  Its first compiler was written in Ocaml.
agumonkey 12y ago
It's funny because ml languages are a lot less alien to the mainstream than before. Things people are used to: - `let` keyword (rust, ES6) - pattern matching (generalization of ES6 destructuring) - function first, HOF combinators (ES5 functional literature) - tuples (python) A few years back, all these would appear as black magic...
- amirmc 12y ago
  You might find the intro to Real World OCaml interesting as these ideas have percolated out from languages such as OCaml. It's great if that helps lower the barrier for people to try it out. https://realworldocaml.org/v1/en/html/prologue.html#why-ocaml https://realworldocaml.org/v1/en/html/prologue.html#why-ocam...
haifeng 12y ago
Thanks for bring Rust into the topic. I know that it is very new. But still wonder if some real life projects are using it (except rustc).

amelius 12y ago

It would be cool to see a "layered" language. By this, I mean a language that has no typing at its lowest level, but you can add it as a library on top of the base level. Then you can add stuff like automatic resolution of calls, etc., as another abstraction level. Of course, you could also add other rules instead of typing. For example, you could pepper your programs with arbitrary proofs, etc., and this could be directed by yet another library on top of your program. Perhaps I'm dreaming. But it sounds like useful to me, as there are so many languages that are almost similar, and yet are slightly different in the way they handle typing and things like polymorphism. It would seem to me that those languages could all share a common base.

haifeng 12y ago
I am not sure if typing can be added as a library. In terms of typed lambda calculus vs untyped lambda calculus, can we do this way? But the idea of "layered" language is nice. In Scala, many features are not really from language itself, but from libraries.
rcsorensen 12y ago
Perl is dynamic enough to support this. See http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/Types.pod http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/... and http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual.pod http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual.... Competing type systems, competing Object systems, and enough internal run-time rewriting to do whatever it is you want. See also http://search.cpan.org/~smueller/Filter-Simple-0.91/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.91/lib/Filt... for a simple rewriting filter, and the Acme namespace for all kinds of fancy experiments.
ufo 12y ago
Optionally typed programming languages are still a big research area and we are just now starting to see some of that research go more mainstream, with things such as Typescript. That said, I don't expect to see a language that does all the things you listed at the same time, since type systems are all about tradeoffs between expressivity and complexity and there is an upper bound in how much complexity a programmer can handle. There are also a lot of other tradeoffs that you need to think about: do unproved assertions get converted to runtime checks or to compile errors? Can you implement that efficiently? How will type inference work? Is it OK to design an unsound type system? etc etc. I can give you some pointers if you want to look for something more specific.