Version française
Home     About     Download     Resources     Contact us    
Browse thread
"OCaml gives you only monomorphic methods in classes."
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Peng Zang <peng.zang@g...>
Subject: Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So I'll pop up here just to say I use a lot of OO in my code.  I do research 
into different techniques of doing (essentially) the same thing.  As a result 
I need to run a lot of benchmarks.  Objects make this ideal.

I will give a simple example.  Suppose you have:

  - 4 different implementations of lists
  - 3 sorting algorithms
  - 2 parameters for generating particular types of lists you care about.

Now suppose you want to find the list implementation and corresponding sorting 
algorithm that yields the best average performance over all the lists you 
care about (those generated by the params).  If lists were implemented as an 
object, then you can do one big list comprehension to get all combinations of 
(list, sorting_alg, data_params).  You can then map over that list running 
the sorting alg with the list implementation on the parameterized data.  A 
simple fold min can then yield the best list implementation and sorting 
algorithm combo.  Very simple and nice.

If the lists were implemented via modules, then the sorting algorithms might 
have to be inside functors.  One can imagine the extra overhead required to 
work with that.  No more nice list comprehension + map + fold = answer. 
Alternatively, you might pass in the say, the 7 or so operations supported by 
lists in addition to the list as arguments to the sorting algorithm.  That 
gets around the problem nicely.  However it can be rather unwieldy to use 
those sort algorithms as they have so many arguments.

One might also consider the use of records.  But then I would argue you're 
basically already in object land and you might as well just use objects.  
Besides which objects gets you things like structural subtyping which is nice 
if for example, some of the list implementations support certain additional 
operations not used in this particular benchmark.

Peng


On Tuesday 08 January 2008 04:42:36 am Jon Harrop wrote:
> On Tuesday 08 January 2008 02:30:31 Jacques Garrigue wrote:
> > From: Jon Harrop <jon@ffconsultancy.com>
> >
> > > I just read this quote and I do not understand what it means:
> > >
> > >   "In particular, the Hindley/Milner style of type inference used in
> > > languages such as OCaml or Haskell is incompatible with lots of
> > > assumptions of OO languages. One incompatibility is with overloading.
> > > That's why OCaml does not let you write + for both integer and floating
> > > point addition. Another incompatibility is with higher order
> > > polymorphism. That's why OCaml gives you only monomorphic methods in
> > > classes." - Martin Odersky
> > >
> > > In what way must methods be monomorphic in OCaml classes?
> >
> > They don't. With the restriction that the types of polymorphic
> > methods cannot be inferred. There is also another subtle
> > limitation, that object are only allowed to have regular
> > types. As a result, one cannot write a polymorphic map method in
> > ocaml, but this is possible in Java 2 or Scala.
>
> This begs a question for me: have people used this functionality in their
> OCaml code?
>
> I personally make virtually no use of OCaml's OOP capabilities at all but I
> make a lot of use of polymorphic variants. In all but a few cases, objects
> seem to be very rarely used by other people in OCaml code. The only notable
> exceptions I can think of are LablGTK2 and PXP.
>
> > I'm quite sure that Martin Odersky is aware of this. I would rather
> > interpret his quote as meaning that you have to extend HM in a
> > non-trivial way to allow this. He was co-author of two papers
> > about extending HM with first-class polymorphism ("putting type
> > annotations to work") and OO (the HM(X) framework), a long time
> > ago too. All these extensions (including the one used in ocaml) have
> > drawbacks, in particular they are either verbose or have bad error
> > messages, or both...
>
> Yes, I believe I misinterpreted Martin's comments. My confusion surrounding
> Scala was why someone researching computer languages would ditch widely
> appreciated features in favour of adding what appear (to me) to be
> seriously obscure gadgets for OO junkies.
>
> I think the reason Martin is focussing on OOP is partly because it is more
> extreme research (whereas cloning OCaml/Haskell is not) and also because it
> is potentially of great value to the huge Java ecosystem (even someone
> high-up at Sun+Google touted Scala as an escape route for Java).
>
> That is a very different goal from trying to improve upon the current
> generation of functional programming languages and is completely different
> to what I was looking for when I found Scala. I'm actually looking for an
> OCaml-like language implementation better suited to my needs rather than a
> wholly different language. Unfortunately, I cannot imagine who, if anyone,
> would build such a thing as an open source project. On the other hand, many
> people have written to me describing why they also believe such a project
> would be of enormous practical value...


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

iD8DBQFHg35kfIRcEFL/JewRAk4cAKCtwqzxab9oA+g6rZAtzm5fca+ezQCgstPr
39l41RASeQxSX4AjSj4byF4=
=tzG7
-----END PGP SIGNATURE-----