caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Peng Zang <peng.zang@gmail.com>
To: caml-list@yquem.inria.fr
Cc: "Jim Farrand" <jim@farrand.net>
Subject: Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)
Date: Thu, 14 Aug 2008 13:13:39 -0400	[thread overview]
Message-ID: <200808141313.42254.peng.zang@gmail.com> (raw)
In-Reply-To: <e16c7bcd0808140904k6ccdf737vc837751bfb8d98be@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 14 August 2008 12:04:23 pm Jim Farrand wrote:
> This doesn't answer my question at all.  :)
>
>  Is there any theoretical reason they couldn't added?  The kind of
> answer I'm looking for is "There is no theoretical reason why not", or
> "This is impossible as it would cause typing in OCaml to become
> undecidable, due to interactions with other features of the OCaml type
> system which aren't present in Haskell."

Oh yeah... oops.  But to answer your question, it appears to be "yes you can":

  http://okmij.org/ftp/ML/ML.html#typeclass

It's not pretty as you have to pass the dictionary by hand, but perhaps some 
camlp4 magic could easy that.  Also, the example given is of rather simple 
type classes, I'm not sure about the full blown thing.


> Though, to address your solution, I am of course aware of it, but it
> has what seem like big disadvantages:
>
> 1. Every value in OCaml would then have to be an object
> 2. Every comparison now requires a relatively expensive dynamic
> dispatch, when the correct function could be determined at runtime.
> 3. If I add a new operator that wasn't thought of by the language
> implementors, it can't be easily added to primitive values, without
> either subclassing all of them, or changing the definition in the
> standard library to add the new method.

1 & 2 are performance concerns that can be addressed as follows:  Let's still 
have polymorphic operators like (=) and "compare".  They will perform their 
normal operation on basic types.  On objects, they will call the object's 
appropriate method.  I have implemented this approach and use it in my own 
code.  It let's me avoid wrapping everything in an object which lets me avoid 
a lot of dynamic dispatches.  (the dispatches are cached so its cost is 
further diluted)

I don't know what to do about 3.  I haven't encountered it thus far.  
Actually, I don't know how type classes help you out here.  Wouldn't you 
still have to modify the type definition of Ints and Floats and whatever 
other standard type to add the new operation?

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFIpGfGfIRcEFL/JewRAmpDAJ4jfgYg0RsBw31Zaw7uDBf9UsqW8wCglk2n
IdeareWjcj7t1lbnXY8k/S8=
=9s95
-----END PGP SIGNATURE-----


  reply	other threads:[~2008-08-14 17:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-14 14:46 Jim Farrand
2008-08-14 15:21 ` [Caml-list] " Peng Zang
2008-08-14 15:38   ` Jon Harrop
2008-08-14 16:04   ` Jim Farrand
2008-08-14 17:13     ` Peng Zang [this message]
2008-08-14 18:37     ` Till Varoquaux
2008-08-15 11:03       ` Wolfgang Lux
2008-08-14 20:53 ` Nathaniel Gray
2008-08-14 22:33   ` Erik de Castro Lopo
2008-08-15  0:21 ` Brian Hurt

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=200808141313.42254.peng.zang@gmail.com \
    --to=peng.zang@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jim@farrand.net \
    /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).