caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: oleg@pobox.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Operator overloading
Date: Fri, 09 Mar 2007 22:09:34 +1100	[thread overview]
Message-ID: <1173438574.22738.24.camel@rosella.wigram> (raw)
In-Reply-To: <20070309073658.8F020AD34@Adric.metnet.fnmoc.navy.mil>

On Thu, 2007-03-08 at 23:36 -0800, oleg@pobox.com wrote:

> John Skaller wrote: ``(Haskell does this little cheat .. it makes
> typeclasses very easy to explain to OO people).'' Are you sure about
> that? There has been many long and recurring threads on Haskell-Cafe
> about typeclasses and OO classes. I think the common advice is _not_
> to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I
> once wanted to elaborate on the issue of OO in Haskell; we ended up
> with a 79-page paper. I guess that shows that OO is never easy.

Certainty requires at least a proof sketch, which I don't have.
However I do have a 'gut feeling' :)

It's hard to say, because in OO terms Haskell typeclasses
are so weak it's surprising they're any use at all.

If you consider your record implementation, observe
it is just a weak special case of a C++ class.
C++ classes can also provide state and inheritance.
The state looks vaguely like dependent typing to me .. :)

OK, so now we have a much more powerful model .. yet
it has known limitations, in particular the so-called
'covariance' problem prevents OO from modelling any
serious kind of system: for example a system
with binary operators doesn't admit an OO representation.

So all you need to do is elevate this model up one kinding
level to see typeclasses, even with the additional power
of 'everything C++ classes can do' are limited.

Of course it is argument by analogy and intuition, not
any kind of formal proof, that's for the experts :)

Felix currently has multi-parameter typeclasses which
use inlining because it's a whole program analyser,
so it can, however explicit objects would be required
either for separate compilation, or simply to experiment
with the 'extra power' of dynamic binding.

The 'obvious' implementation is of course a C++ class.

The difference to ordinary use is that the object doesn't
represent a type, but a typeclass, possibly with dependent
type parameters: eg a 'get' method for an array with
the length as a state variable.




-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-03-09 11:09 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-09  7:36 oleg
2007-03-09 11:09 ` skaller [this message]
2007-03-09 13:52   ` [Caml-list] " Andreas Rossberg
2007-03-09 15:07     ` skaller
2007-03-09 16:28       ` Andreas Rossberg
2007-03-10  3:13         ` skaller
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 16:40 Robert Fischer
2007-03-09 17:25 ` Jon Harrop
2007-03-08 23:20 Robert Fischer
2007-03-09 10:31 ` Jon Harrop
2007-03-08 20:02 Robert Fischer
2007-03-08 20:15 ` Michael Hicks
2007-03-08 20:50   ` Brian Hurt
2007-03-08 21:05 ` Tom
2007-03-08 21:31   ` Brian Hurt
2007-03-08 22:09     ` Michael Vanier
2007-03-08 22:34     ` Till Varoquaux
2007-03-09 16:02       ` Brian Hurt
2007-03-10  3:23         ` skaller
2007-03-08 22:14   ` Ian Zimmerman
2007-03-09 10:29     ` Jon Harrop
2007-03-09 16:28       ` Ian Zimmerman
2007-03-08 23:51 ` skaller
2007-03-09  7:23   ` Tom
2007-03-09  9:24     ` skaller
2007-03-09  9:32       ` Tom
2007-03-09 10:00         ` skaller
2007-03-09 10:14         ` Jon Harrop
2007-03-09 10:38   ` Jon Harrop
2007-03-09 10:20 ` Jon Harrop
2007-03-09 12:08 ` Andrej Bauer
2007-03-09 12:48   ` Jacques Carette
2007-03-09 13:24   ` Andreas Rossberg
2007-03-10  5:08   ` Daniel Andor
2007-03-10  5:33     ` David Thomas
2007-03-08 14:41 [Caml-list] F# Robert Fischer
2007-03-08 17:30 ` Roland Zumkeller
2007-03-08 17:54   ` Brian Hurt
2007-03-08 19:40     ` [Caml-list] Operator overloading Jon Harrop
2007-03-08 20:44       ` Brian Hurt
2007-03-08 22:24       ` Fernando Alegre
2002-04-15 17:05 [Caml-list] operator overloading Issac Trotts
2002-04-14  4:15 Issac Trotts
2002-04-13  8:43 forsyth
2002-04-13  5:26 Issac Trotts
2002-04-13  1:32 Gurr, David (MED, self)
2002-04-12 19:08 Issac Trotts
2002-04-13  8:48 ` William Chesters
2002-04-13 13:58   ` Brian Rogoff
2002-04-13 15:31     ` William Chesters
2002-04-14  3:10       ` Brian Rogoff
2002-04-13  9:00 ` Daniel de Rauglaudre
2002-04-13 21:35 ` Johan Georg Granström
2002-04-14  1:50   ` Jacques Garrigue
2002-04-15 16:22 ` Jun P.FURUSE

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=1173438574.22738.24.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=oleg@pobox.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).