caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: dra-news@metastack.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] What is a future of ocaml?
Date: Thu, 15 Jan 2009 21:13:35 +0900 (JST)	[thread overview]
Message-ID: <20090115.211335.27794984.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <001801c9765e$4fabc3b0$ef034b10$@com>

From: "David Allsopp" <dra-news@metastack.com>
> Dawid Toton wrote:
> > Could anybody explain why it's impossible to have type classes in OCaml?
> 
> I don't think it's impossible - but I believe that if you introduce type
> classes then you "damage" Hindley-Milner type inference and you can no
> longer derive a principal typing for an arbitrary ML expression without
> resorting to type annotations. Whether this is a problem or not is a matter
> of taste - but it does make the language harder to call "ML" if you lose one
> of its central features! That said, there are of course two big features
> (objects and polymorphic variants) in OCaml already which do require
> annotations.

The reason is mostly wrong :-)
One can have both type classes and principal types; the problem with
principal types in Haskell is more subtle thant that.
And neither polymorphic variants nor object require type anotations in
ocaml; they just make it much more painful to understand error
messages.
Principality is only broken by optional arguments and polymorphic
methods, and there is a -principal flag that recovers some form of
principality (requiring type annotations).

This said, type classes have a lot of common features with modules or
objects, so this would be yet another way to do some similar things.
More problematic, type classes depend on the nominality of the type
systems, while ocaml has a rich language of structural types. For
instance, it is not completely clear how one could select instances of
type classes for polymorphic variants, without introducing conflicts.
I'm afraid the combination of type classes with modules and functors
is not trivial either.

Jacques Garrigue


  reply	other threads:[~2009-01-15 12:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-14  9:18 Radzevich Belevich
2009-01-14  9:35 ` [Caml-list] " David Allsopp
2009-01-14  9:51 ` Richard Jones
2009-01-14 13:34 ` Sylvain Le Gall
2009-01-14 13:44 ` [Caml-list] " Dawid Toton
2009-01-14 15:37   ` Martin Jambon
2009-01-14 15:39   ` David Allsopp
2009-01-15 12:13     ` Jacques Garrigue [this message]
2009-01-15 12:46       ` Benedikt Grundmann
2009-01-15 22:20         ` Oliver Bandel
2009-01-16 14:56           ` Kuba Ober
2009-01-15 12:51       ` David Allsopp
2009-01-15 21:08       ` Stefan Monnier
2009-01-14 16:07   ` [Caml-list] " Jérémie Dimino
2009-01-14 17:28   ` Dario Teixeira
2009-01-15 17:50     ` Richard Jones
2009-01-15 17:46   ` Richard Jones
2009-01-18 16:34     ` Xavier Leroy
2009-01-18 18:02       ` Richard Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090115.211335.27794984.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@yquem.inria.fr \
    --cc=dra-news@metastack.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).