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-----
next prev parent 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