

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

======
gnuvince
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.

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

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

~~~
mercurial
> building a little HTTP server
    
    
        opam install cohttp
    

> command-line tool
    
    
        opam install cmdliner
    

> Go has a great batteries-included standard library.

OCaml doesn't, but there are good stdlib replacements, and its package manager
is really nice.

~~~
AceJohnny2
I tried to use Opam on Debian Unstable a few months ago. It was 1.1.0.

When requested to install a second package with overlapping dependencies as a
previous package, it would try reinstalling _all_ dependencies, including
previously installed ones, and would fail.

That is, in my book, an epic fail for a package manager, let alone a
supposedly >1.0 version (if that even means anything today). I'm still annoyed
about that. Searching online found recommendations to get the latest version
from Github.

1.2.0 has since been released and included in Debian. I keep meaning to give
it another go, but I must admit being wary after that first experience.

~~~
avsm
> When requested to install a second package with overlapping dependencies as
> a previous package, it would try reinstalling all dependencies

This was unfortunately a mistake made by upstream Debian. Rather than
reimplement the constraint solver badly, we use the Aspcud external solver. An
upgrade of Aspcud changed its command-line interface, and OPAM 1.1.0 wasn't
upgraded to OPAM 1.1.1 at the same time (which detected the new version of
Aspcud and worked with it).

A similar issue (to do with the libdose interface) has been in the Ubuntu
package ages and not addressed by upstream despite a detailed bug report:
[https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346](https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346)

> Searching online found recommendations to get the latest version from Github

What else could we recommend?

It's really frustrating to know that a source-compiled OPAM works fine, but
that the packaged binary versions are broken and our only recourse is to wait
six months for the next OS release of Ubuntu. On the bright side, the OPAM
1.2.x series has been very stable and is now making its way upstream, so this
is hopefully a temporary issue.

~~~
e12e
That explains a lot. I thought opam was behaving better now, than I recall it
did at some random point in the past.

I'm really grateful to everyone doing all this work. This is a typical example
of the kind of "excitement" mixing distro package managers and language
package managers can lead to. The only recourse is to file a bug, maybe
provide a backport if feasible, and move on -- and have everyone (package
maintainers, distros) be a little wiser, and (hopefully) everything working on
the next release.

Anyway, I see I have opam in my ~/bin -- so clearly I've compiled it myself at
some point. No wonder, as I'm still running stable on this laptop:

[https://packages.debian.org/search?keywords=opam&searchon=na...](https://packages.debian.org/search?keywords=opam&searchon=names&suite=all&section=all)

Maybe there should be a note in the wiki about it, although it should be
resolved when jessie is out?:

[https://wiki.debian.org/OCaml](https://wiki.debian.org/OCaml)

(Yeah, I know, it's a wiki. I could just add it. I don't feel quite confident
enough to go and clutter such a short little page, though. Different if
there's a page where "someone is wrong on the internet".)

------
zaphar
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.

~~~
panic
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
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
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
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
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.

------
amelius
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.

~~~
rcsorensen
Perl is dynamic enough to support this.

See
[http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/...](http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/Types.pod)
and
[http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual....](http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual.pod)

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...](http://search.cpan.org/~smueller/Filter-
Simple-0.91/lib/Filter/Simple.pm) for a simple rewriting filter, and the Acme
namespace for all kinds of fancy experiments.

