"OCaml gives you only monomorphic methods in classes."

"OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

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?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Gordon Henriksen]

Jon, consider the case of Java or C++ method (and function)  
overloading. This form of static dispatch is quite distinct from  
virtual method dispatch, and is indeed at odds with type inference.

- Gordon

On Dec 28, 2007, at 16:37, Jon Harrop <jon@ffconsultancy.com> wrote:

>
> 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?
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

On Friday 28 December 2007 23:55:32 Gordon Henriksen wrote:
> Jon, consider the case of Java or C++ method (and function)
> overloading. This form of static dispatch is quite distinct from
> virtual method dispatch, and is indeed at odds with type inference.

I see. Still, the solution seems easy enough. Just treat the overloaded types 
as part of the function name:

  foo(int n)
  foo(float x)
  foo(string s)

becomes:

  foo_int n
  foo_float x
  foo_string s

When you come across:

  foo(a)

you look up the statically inferred type of "a" and just bail if it fails to 
match any of the overloads.

Generics are left alone:

  foo<T>(T x)

becomes:

  foo (x : 'T)

Would that work?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Gordon Henriksen]

Oh, were you proposing a language feature? In that case, consider:

let bar x = foo x

How to compile that?

- Gordon

On Dec 28, 2007, at 17:27, Jon Harrop <jon@ffconsultancy.com> wrote:

> On Friday 28 December 2007 23:55:32 Gordon Henriksen wrote:
>> Jon, consider the case of Java or C++ method (and function)
>> overloading. This form of static dispatch is quite distinct from
>> virtual method dispatch, and is indeed at odds with type inference.
>
> I see. Still, the solution seems easy enough. Just treat the  
> overloaded types
> as part of the function name:
>
>  foo(int n)
>  foo(float x)
>  foo(string s)
>
> becomes:
>
>  foo_int n
>  foo_float x
>  foo_string s
>
> When you come across:
>
>  foo(a)
>
> you look up the statically inferred type of "a" and just bail if it  
> fails to
> match any of the overloads.
>
> Generics are left alone:
>
>  foo<T>(T x)
>
> becomes:
>
>  foo (x : 'T)
>
> Would that work?
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

On Saturday 29 December 2007 01:19:53 Gordon Henriksen wrote:
> Oh, were you proposing a language feature? In that case, consider:
>
> let bar x = foo x
>
> How to compile that?

The call to "foo" uses an argument with the type '_a. That is the bail case, 
giving an error saying that overloads require type annotations. I think this 
is exactly what F# does. If you wanted to be more fancy you could allow that 
and just copy the requirements upon "x". So if you know foo's argument is 
[int|string] then bar's argument would also be [int|string].

I'm not proposing language features so much as just trying to understand 
Martin's assertion that integrating statically-typed FP with 
nominally-subtyped OOP is an unsolved problem. This doesn't even seem hard, 
let alone unsolved, but I can't think what I'm missing.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Dylan William Hardison]

Spake Jon Harrop on Friday, December 28, 2007 at 11:37PM +0000:
> 
> 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

This seems correct for O'Caml (and SML?) but not Haskell.
Haskell's type system is extended with type classes, which allow + and such to
be overloaded...

-- 
"Regardless of the legal speed limit, your Buick must be operated at
speeds faster than 85 MPH (140kph)."
              -- 1987 Buick Grand National owners manual.
-
GPG Fingerprint: 412C CCE9 DDA2 4FE9 C34F  754B 0863 0EA6 712E BBE1

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[brogoff]

On Fri, 28 Dec 2007, Jon Harrop wrote:
> 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

What's the date that quote was made? It was probably made before
polymorphic methods were added to OCaml from OLabl.

> In what way must methods be monomorphic in OCaml classes?

They don't need to be.  See section 3.11 of "Objects in Caml" of the
manual.

-- Brian

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

On Saturday 29 December 2007 04:31:02 Dylan William Hardison wrote:
> This seems correct for O'Caml (and SML?) but not Haskell.
> Haskell's type system is extended with type classes, which allow + and such
> to be overloaded...

Yes, that's what I said. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

On Saturday 29 December 2007 06:30:48 brogoff wrote:
> What's the date that quote was made?

Yesterday, by the professor heading the group at Lausanne who are developing 
one of the most widely touted modern statically-typed functional programming 
languages (Scala).

> It was probably made before polymorphic methods were added to OCaml from
> OLabl. 

Looks like polymorphic methods have been in OCaml for 5 years now:

http://caml.inria.fr/pub/ml-archives/caml-list/2002/07/0efd71474f4d41a39e4250aeddcf08e5.en.html

This is really ossifying my impression that the Scala developers (let alone 
the community) are not aware of the current state-of-the-art in statically 
typed functional programming languages despite the fact that their sole 
purpose is to improve upon them.

Unfortunately, this is rubbing off on the Scala community who keep publishing 
articles making silly claims like "Scala is the first impure functional 
programming language".

I wouldn't mind this so much whilst learning the language if it weren't for 
the fact that it is sorely lacking in so many respects.

I'm currently torn between devoting time to learning Scala or to a new system 
based upon LLVM and targetted at technical users (e.g. high performance 
numerics), commerce (e.g. DLLs) and visualization (e.g. Smoke and OpenGL 2). 
Things like this keep pushing me towards LLVM. Well, this and the fact that 
Gordon's bindings make LLVM so much damn fun. ;-)

Happy New Year,
-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[brogoff]

On Sat, 29 Dec 2007, Jon Harrop wrote:

> On Saturday 29 December 2007 06:30:48 brogoff wrote:
> > What's the date that quote was made?
>
> Yesterday, by the professor heading the group at Lausanne who are developing
> one of the most widely touted modern statically-typed functional programming
> languages (Scala).

Then Dr. Odersky and his listeners would be well served by a polite
correction. As Scala has been changing rapidly over the past year, he
surely understands that comments made on a 2 year old version of Scala
(Scala lacks lazy values, and structural typing, and existential types,
and...) don't reflect the current state of the language.

Other than that, I wouldn't let such comments deter me from investing
time in the language. If it does what I want (interoperate with the JVM
and Java) then what the users believe about OCaml is hardly relevant.

-- Brian

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Kuba Ober]

> >> Jon, consider the case of Java or C++ method (and function)
> >> overloading. This form of static dispatch is quite distinct from
> >> virtual method dispatch, and is indeed at odds with type inference.
> >
> > I see. Still, the solution seems easy enough. Just treat the
> > overloaded types
> > as part of the function name:
> >  foo(int n)
> > becomes:
> >  foo_int n
> > When you come across:
> >  foo(a)
> > you look up the statically inferred type of "a" and just bail if it
> > fails to
> > match any of the overloads.

> Oh, were you proposing a language feature? In that case, consider:
> let bar x = foo x
> How to compile that?

Check for all foo_xxx, and expand to
let bar_int x = foo_int x
let bar_float x = foo_float x
and so on.

The only thing I'm worried about is the fact that for one type,
there doesn't necessarily need to be a foo_xxx function. This naming solution 
isn't overly clean, so maybe it'd be better to do it slightly differently.

What about having the function name implicitly reference the signature, and do 
pattern matching on that?

So let's say we'd have

let add x y = x + y
let add x y = x + int_of_float y
let add x y = x +. y

let add2 x y = (x + 1) + (y - 1)
let add2 x y = (x + 1) + (int_of_float y - 1)
let add2 x y = (x +. 1.) + (y -. 1.)

And now we do

let add (x : int) y = add2 x y

This would replace the first two add functions, but not the third.

Presumably, for this feature to be safe to add to the language, there should
be some syntactic sugar to conveniently enable it for a function. No clue how
that'd look.

This would be a very useful addition to the language, although I'm sure it 
could make compilation longer in some cases, as the type inferrer would have
more choices to work with.

The "good old" mangling of the signature into the symbol is something we'd 
better not have to do manually.

For now I'm working on a very basic C++-to-Ocaml "converter" (in the spirit of 
web2c, i.e. only to work on one codebase), and this is definitely one of the 
issues I'm facing, as the code pretty much uses the whole spectrum of C++ 
features.

Cheers, Kuba

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jacques Garrigue]

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.

> On Saturday 29 December 2007 06:30:48 brogoff wrote:
> > What's the date that quote was made?
> 
> Yesterday, by the professor heading the group at Lausanne who are developing 
> one of the most widely touted modern statically-typed functional programming 
> languages (Scala).
> 
> > It was probably made before polymorphic methods were added to OCaml from
> > OLabl. 
> 
> Looks like polymorphic methods have been in OCaml for 5 years now:
> 
> http://caml.inria.fr/pub/ml-archives/caml-list/2002/07/0efd71474f4d41a39e4250aeddcf08e5.en.html

Actually, this is now close to 10 years if you include the OLabl
distribution... The original paper on adding semi-implicit first-class
polymorphism to HM was published in 1997.

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...

Anyway, you should not underestimate his contribution to this area of
work.

> This is really ossifying my impression that the Scala developers (let alone 
> the community) are not aware of the current state-of-the-art in statically 
> typed functional programming languages despite the fact that their sole 
> purpose is to improve upon them.
> 
> Unfortunately, this is rubbing off on the Scala community who keep publishing 
> articles making silly claims like "Scala is the first impure functional 
> programming language".

This is maybe not fully correct, but at least one can say that Scala
is "the most impure of functional languages" :-)

Cheers,

Jacques Garrigue

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Jon Harrop]

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...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Peng Zang]

-----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-----

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[brogoff]

On Tue, 8 Jan 2008, Jon Harrop wrote:
> On Tuesday 08 January 2008 02:30:31 Jacques Garrigue wrote:
> > From: Jon Harrop <jon@ffconsultancy.com>
> > > 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 don't understand your question. How could we use this functionality in
our OCaml code if it doesn't exist? You must mean something else,
perhaps "do I use polymorphic methods in my OCaml code?". Not now. I
did when translating some purely functional data structures from
Okasaki's book to OCaml, then rewrote them using the higher
order polymorphism of record fields, which we got at the same time, a
workaround to the lack of polymorphic recursion in OCaml.

> I personally make virtually no use of OCaml's OOP capabilities at all but I

Very punny ;-)

> 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 use them when I have record field name clashes and I decide that this
aspect of OCaml records hinders rather than helps readability. It is an
interesting topic, certainly. Pattern matching is less useful on records
than variants (IMO of course) so the fact that we don't have it on
objects doesn't bother me all that much. But in my experience I need to
provide a lot more explicit typing when using the OOP features than I'm
used to, in order to get comprehensible error messages.

> > 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.

If the original quote was accurate, then I think this is quite generous,
as it seemed the statement was 'OCaml doesn't have polymorphic methods,
period-end-of-story".

Scala does look very interesting though, and if I need to work in a JVM
environment I'll seriously consider using it.

-- Brian

Re: [Caml-list] "OCaml gives you only monomorphic methods in classes."

[Paolo Donadeo]

> This begs a question for me: have people used this functionality in their
> OCaml code?

I use OOP heavily, along with the other more functional features of
the language.

In my opinion the object oriented support offered by OCaml is
excellent and largely undervalued, probably because people using OCaml
have probably never programmed in Java ;-)

In OCaml I have the chance to choice the granularity and the paradigm
which best fits the particular problem I'm confronting with and *this*
is great.


-- 
                                            Paolo


Paolo Donadeo, Senior Software Engineer
Studio Associato 4Sigma
Email: p.donadeo@4sigma.it
~
~
:wq