Typeclasses in OCaml (Was: Haskell vs OCaml)

Typeclasses in OCaml (Was: Haskell vs OCaml)

[Jim Farrand]

2008/8/14 Peng Zang <peng.zang@gmail.com>:

> In Haskell you can write a function that takes anything that is "showable" (a
> type class) and print it out.  The sig would be something like (I'm mixing
> OCaml and Haskell syntax here, but hopefully the point is still clear):

Out of curiosity, are there any theoretical reasons why OCaml could
not be extended with type classes?  They are one of my favourite
features of Haskell, and I think they would really improve OCaml.

Things like the (=) operator in OCaml vex me.  One of the big
advantages of static typing and type inference is that stupid
programmer errors are prevented at compile time.  However, the (=)
operator in OCaml is effectively meaningless for a lot of types, yet
there is no way to prevent a programmer from accidentally calling it.

One way to get around this would be to take away (=) and (==) and
replace them with specific versions for each type (just like we already
have (+) and (+.) etc) but this leads to really verbose code.

Type classes solve this kind of problem very effectively.

Regards,
Jim

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Peng Zang]

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

On Thursday 14 August 2008 10:46:41 am Jim Farrand wrote:
> Things like the (=) operator in OCaml vex me.  One of the big
> advantages of static typing and type inference is that stupid
> programmer errors are prevented at compile time.  However, the (=)
> operator in OCaml is effectively meaningless for a lot of types, yet
> there is no way to prevent a programmer from accidentally calling it.
>
> One way to get around this would be to take away (=) and (==) and
> replace them with specific versions for each type (just like we already
> have (+) and (+.) etc) but this leads to really verbose code.
>
> Type classes solve this kind of problem very effectively.
>
> Regards,
> Jim
>

- From what I was told earlier on this list, if you want type classes in OCaml 
you go with objects.  So you would not have:

  (=) : 'a -> 'a -> bool

But instead:

  (=) : (#equatable as 'a) -> 'a -> bool

where

  class type equatable = object
    method equals : 'self -> bool
  end


This gives all the advantages of static typing and type inference and prevents 
stupid errors and it is meaningful for all types that it is implemented for.


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

iD8DBQFIpE11fIRcEFL/JewRAmyEAKCIbPDMFVh+zuCQ5uD/t+FNPXRJ2gCgwTTl
ZELl4dYgZvnh8cAhlnN2gb0=
=7pTp
-----END PGP SIGNATURE-----

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Jon Harrop]

On Thursday 14 August 2008 16:21:22 Peng Zang wrote:
> This gives all the advantages of static typing and type inference and
> prevents stupid errors and it is meaningful for all types that it is
> implemented for.

That is essentially the solution that F# uses.

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

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Jim Farrand]

2008/8/14 Peng Zang <peng.zang@gmail.com>:

>  (=) : 'a -> 'a -> bool
>
> But instead:
>
>  (=) : (#equatable as 'a) -> 'a -> bool
>
> where
>
>  class type equatable = object
>    method equals : 'self -> bool
>  end
>
>
> This gives all the advantages of static typing and type inference and prevents
> stupid errors and it is meaningful for all types that it is implemented for.

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

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.

Regards,
Jim

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Peng Zang]

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

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Till Varoquaux]

Typw inference in haskell is not decideable (nor is it in ocaml when
using objects) and you have to provide some type information. I would
much rather trade some inference for more power in the type system
(value restriction and lack of higher rank polymorphic really kill
some coding styles....) but thta is a matter of taste. Didier Remy is
working on ML F which should address those.

On top of breaking inference type cleases come at a high run tine
cost. You can regain a lot by doing ad-hoc optimizations but this is
quite far from OCaml's philosophy: the compiler's optimisations (or
lack thereof) are very predictable which is nice once you move out of
toy programs.

Till
On Thu, Aug 14, 2008 at 5:04 PM, Jim Farrand <jim@farrand.net> wrote:
> 2008/8/14 Peng Zang <peng.zang@gmail.com>:
>
>>  (=) : 'a -> 'a -> bool
>>
>> But instead:
>>
>>  (=) : (#equatable as 'a) -> 'a -> bool
>>
>> where
>>
>>  class type equatable = object
>>    method equals : 'self -> bool
>>  end
>>
>>
>> This gives all the advantages of static typing and type inference and prevents
>> stupid errors and it is meaningful for all types that it is implemented for.
>
> 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."
>
> 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.
>
> Regards,
> Jim
>
> _______________________________________________
> 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] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Wolfgang Lux]

Till Varoquaux wrote:

> Typw inference in haskell is not decideable (nor is it in ocaml when
> using objects) and you have to provide some type information.

Huh? The only thing that is not decidable in Haskell's type system is  
polymorphic recursion. Apart from that you do not need any type  
annotations (except in order to get around Haskell's monomorphism  
restriction, but that is a different story).

> On top of breaking inference type cleases come at a high run tine
> cost.

Type classes do not break type inference. Just read Mark P. Jones's  
papers.

Regards
Wolfgang

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Nathaniel Gray]

On Thu, Aug 14, 2008 at 7:46 AM, Jim Farrand <jim@farrand.net> wrote:
> 2008/8/14 Peng Zang <peng.zang@gmail.com>:
>
>> In Haskell you can write a function that takes anything that is "showable" (a
>> type class) and print it out.  The sig would be something like (I'm mixing
>> OCaml and Haskell syntax here, but hopefully the point is still clear):
>
> Out of curiosity, are there any theoretical reasons why OCaml could
> not be extended with type classes?  They are one of my favourite
> features of Haskell, and I think they would really improve OCaml.

It could be done.  See this paper from POPL '07:

http://portal.acm.org/citation.cfm?id=1190215.1190229

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Erik de Castro Lopo]

Nathaniel Gray wrote:

> It could be done.  See this paper from POPL '07:
> 
> http://portal.acm.org/citation.cfm?id=1190215.1190229

That paper seems to be stuck behind the ACM's knowledge firewall and
hence out of reach for people like me.

Fortunately, it also seems to be available here:

    http://www.cse.unsw.edu.au/~chak/papers/DHC07.html


Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"XML is not a language in the sense of a programming language any
more than sketches on a napkin are a language." -- Charles Simonyi

Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml)

[Brian Hurt]

On Thu, 14 Aug 2008, Jim Farrand wrote:

> 2008/8/14 Peng Zang <peng.zang@gmail.com>:
>
> Out of curiosity, are there any theoretical reasons why OCaml could
> not be extended with type classes?  They are one of my favourite
> features of Haskell, and I think they would really improve OCaml.

Because everything you can do with type classes you can do with monads and 
functors, and vice-versa.  If you're thinking "hey, this would be a real 
nice function to have type classes for", try functorizing it.  Use the 
features the language already has, instead of wishing for new ones.

Some things are clunky to do in functors, I agree, but the same can be 
said of type classes- and I'm far from convinced that type classes are 
innately a better idea than functors.

Brian