OCaml: Polymorphism

http://haifengl.wordpress.com/2014/07/08/ocaml-polymorphism/

by haifeng • 11 years ago

71 42 11 years ago

haifengl.wordpress.com

zaphar• 11 years 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.

haifeng6• 11 years 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.

ufo4• 11 years ago

parametric polymorphism also give you "theorems for free" if you choose the right places to put your abstractions.

panic• 11 years ago

OCaml models "interface" polymorphism using an extension to parametric polymorphism called row polymorphism (https://realworldocaml.org/v1/en/html/objects.html), which lets you avoid subtyping even for interface types.

dougk162• 11 years 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).

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.

haifeng6• 11 years 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.

dougk162• 11 years 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. :)

tel2• 11 years 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...

gnuvince2• 11 years 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• 11 years ago

The Rust language itself has a noticeably heavy ML influence.

haifeng6• 11 years ago

An ML with many C notations :)

Chattered• 11 years ago

Its first compiler was written in Ocaml.

agumonkey• 11 years 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...

amirmc3• 11 years 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-ocam...

haifeng6• 11 years 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).

Rusky• 11 years ago

Mozilla Servo is a browser engine written in Rust; skylight.io is a Ruby Gem written in Rust. Then there are several smaller projects for game engines, web server stuff, cryptography, etc.

wtetzner• 11 years ago

It doesn't have the get-shit-done reputation of Go, but it should. I personally find that OCaml is a very pragmatic language.

gnuvince2• 11 years ago

Oh, absolutely!

zimbatm• 11 years ago

What's the story for building a little HTTP server or command-line tool ? Go has a great batteries-included standard library.

amelius• 11 years 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.

haifeng6• 11 years 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• 11 years ago

Perl is dynamic enough to support this.

See http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/... and 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/Filt... for a simple rewriting filter, and the Acme namespace for all kinds of fancy experiments.

ufo4• 11 years 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.

kibwen• 11 years ago

Noether is a "layered" language like you describe, as it's actually a set of seven languages arranged in a hierarchy where each layer adds a feature to the one below it, with the tradeoff being that as you add features you lessen your ability to reason about aspects of your code. See https://github.com/noether-lang/noether/blob/master/doc/pres... and skip down the slide "Sublanguages and their symmetries".

OCaml: Polymorphism

Related Stories