Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] OCaml wishlist
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Brown <caml-list@d...>
Subject: Re: [Caml-list] OCaml wishlist
On Tue, Oct 21, 2003 at 03:29:21PM +0100, Richard Jones wrote:

> 1. 'return' from a function. eg:
> 
>   let foo x =
>     if x < 0 then return "OSL";
>     (* long & complex code *)
>     return "some other string"

let return x = x

> 2. abstract data type syntactic sugar:
> 
>    let hash = Hashtbl.create 16 in
>    hash#add "foo" 10;		or:   hash->add "foo" 10;
>    hash#add "bar" 20;		or:   hash->add "bar" 20;
> 
>    The syntactic sugar is that if a module contains a type called
>    M.t (literally "type t"), and obj has type M.t, then:
> 
>    obj#call		      [	or:   obj->call ]
> 
>    is exactly equivalent to:
> 
>    M.call obj

As pointed out in another post, there are type issues with this.  These
new constructs have to be polymorphic in the same ways that objects are.
If you want an object interface to something, it is probably best to
just do it that way.

>    I think this change would help a lot of Java programmers (<gr>) who
>    would otherwise tend to jump immediately on using objects, which are
>    an area where OCaml is weaker.

I'm curious what the argument for Ocaml objects being weaker is.  For
the most part, the OCaml object system is much more flexible, mostly
because class inheritance and type inheritance are kept seperate.  Are
you complaining that coersion has to be explicit, and that you can't
cast to a more specific type?

I would suspect most instances of needing these casts in Java is due to
Java's much weaker type system.

There are some problems where an OO solution maps well to the problem.
There are many other problems where trying to force it into an OO model
only obscures the problem.  Ocaml is nice in that it gives you a choice.
The flexibility occasionally means that a particular model may not be as
easy to use as in a language where that is the only model available.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners