The "Objective" part of Objective Caml

The "Objective" part of Objective Caml

[Florian Weimer]

I was a bit surprised when I started playing with Caml objects.  I
couldn't find a definite reference, but it seems that the object
system was indeed inspired by the "Objective" family of languages (the
"evolutionary approach" to add a Smalltalk-like object system
described by Brad Cox in the 80s, later picked up by NeXT).  Is this
really the case?  Or is the similarity just a coincidence?

Ant: [Caml-list] The "Objective" part of Objective Caml

[Martin Chabr]

--- Florian Weimer <fw@deneb.enyo.de> wrote:

> I was a bit surprised when I started playing with
> Caml objects.  I
> couldn't find a definite reference, but it seems
> that the object
> system was indeed inspired by the "Objective" family
> of languages (the
> "evolutionary approach" to add a Smalltalk-like
> object system
> described by Brad Cox in the 80s, later picked up by
> NeXT).  Is this
> really the case?  Or is the similarity just a
> coincidence?

The object oriented part of OCaml is roughly speaking
just as capable as that of Python, C++, Java, C# etc.

You get a nice overview in these 4 online books:

1. O'Reilly book on OCaml
at http://caml.inria.fr/pub/docs/oreilly-book/

2. Jason Hickey's tutorial
3. Merjis tutorial by Rich Jones
4. a little more advanced treatise by Didier Rémy
- these 3 and others at
http://pauillac.inria.fr/caml/tutorials-eng.html

Have fun!


Regards,

Martin


	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Florian Weimer]

* Martin Chabr:

> --- Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> I was a bit surprised when I started playing with Caml objects.  I
>> couldn't find a definite reference, but it seems that the object
>> system was indeed inspired by the "Objective" family of languages
>> (the "evolutionary approach" to add a Smalltalk-like object system
>> described by Brad Cox in the 80s, later picked up by NeXT).  Is
>> this really the case?  Or is the similarity just a coincidence?
>
> The object oriented part of OCaml is roughly speaking
> just as capable as that of Python, C++, Java, C# etc.

Sure, I don't doubt that.  I'm interested in the genesis of the object
system, though, and if the structural similarity to the Objective C
effort by Brad Cox is just a coincidence, or was deliberate.

(There is a significant difference, though, because Objective Caml
uses static type checks to ensure that every message has a receiver.)

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[skaller]

On Mon, 2005-11-07 at 22:55 +0100, Florian Weimer wrote:
> * Martin Chabr:
> 
> > --- Florian Weimer <fw@deneb.enyo.de> wrote:
> >
> >> I was a bit surprised when I started playing with Caml objects.  I
> >> couldn't find a definite reference, but it seems that the object
> >> system was indeed inspired by the "Objective" family of languages
> >> (the "evolutionary approach" to add a Smalltalk-like object system
> >> described by Brad Cox in the 80s, later picked up by NeXT).  Is
> >> this really the case?  Or is the similarity just a coincidence?
> >
> > The object oriented part of OCaml is roughly speaking
> > just as capable as that of Python, C++, Java, C# etc.
> 
> Sure, I don't doubt that. 

I do. The Python system is much more 'capable' and much less 'robust'.
This is typical for dynamic typing vs static typing.

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

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Brian Hurt]

On Tue, 8 Nov 2005, skaller wrote:

>>> The object oriented part of OCaml is roughly speaking
>>> just as capable as that of Python, C++, Java, C# etc.
>>
>> Sure, I don't doubt that.
>
> I do. The Python system is much more 'capable' and much less 'robust'.
> This is typical for dynamic typing vs static typing.

I think I'm with Skaller here- Objects in Ocaml are much less powerfull 
than they are in (for example) Java or Python.  For example, objects in 
Ocaml can not have non-virtual (non-overloadable) methods, or static 
(global) methods.  So patterns like singletons are hard to implement with 
Ocaml objects.

But that's OK- because Ocaml provides other ways to provide those 
capabilities.  The problem I have with a lot of pure-OO languages is the 
need to make objects do everything.  The proper way to do a singleton in 
Ocaml is to use modules, not objects.  If you're not using the true power 
of objects- inheritance, virtual functions, and overloading- you shouldn't 
be using objects.  So the fact that Ocaml doesn't provide support for 
these non-objects isn't a problem.

Brian

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Daniel Bünzli]

Le 8 nov. 05 à 03:15, Brian Hurt a écrit :

> So patterns like singletons are hard to implement with Ocaml objects.

Don't you have immediate objects [1] to do singletons ?

Daniel

[1] <http://caml.inria.fr/pub/docs/manual-ocaml/ 
manual005.html#ss:immediate-objects>

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Brian Hurt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 719 bytes --]



On Tue, 8 Nov 2005, Daniel Bünzli wrote:

>
> Le 8 nov. 05 à 03:15, Brian Hurt a écrit :
>
>> So patterns like singletons are hard to implement with Ocaml objects.
>
> Don't you have immediate objects [1] to do singletons ?

No- because immediate objects still allocate a new object every time they 
are evaluated.  I suppose you could do:

let factory =
     let myobject = new myclass in
     fun () -> myobject
;;

and do a factory method, but there is no way (that I know of) to prevent 
someone else from doing:
     let myotherobject = new myclass
and allocating a different object of the same class.

No, the proper way to do singletons in Ocaml is with modules, not objects.

Brian

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Alexander Fuchs]

Brian Hurt wrote:
> No, the proper way to do singletons in Ocaml is with modules, not objects.

I am not sure if you meant this by 'modules, not objects', but what 
about specifying only the class type interface of the singleton, but not 
the interface of the actual singleton class in the module interface:

singleton.mli:
---------------------------
(* class signature of the singleton *)
class type foo =
object
   method print_id: unit
end

(* the singleton *)
val singleton: foo
---------------------------


singleton.ml:
---------------------------
(* copied from the interface *)
class type foo =
object
   method print_id: unit
end

(* the class of the singleton *)
class bar id =
object
   val id = id
   method print_id = print_endline (string_of_int id);
end

(* the singleton *)
let singleton =
   new bar 0
---------------------------


Now you can access:
Singleton.singleton;;

but not create (as foo is just an interface):
new Singleton.foo 1;;

and not create (as bar is not exported to the interface):
new Singleton.bar 2;;

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Matt Gushee]

Brian Hurt wrote:

>> Don't you have immediate objects [1] to do singletons ?
> 
> 
> No- because immediate objects still allocate a new object every time
> they are evaluated.  I suppose you could do:
> 
> let factory =
>     let myobject = new myclass in
>     fun () -> myobject
> ;;
> 
> and do a factory method, but there is no way (that I know of) to prevent
> someone else from doing:
>     let myotherobject = new myclass
> and allocating a different object of the same class.

Just for amusement, here are two ways:

[1]

   let factory =
     let instance_exists = ref false in
     let mkobj () =
       object
         initializer
           if !instance_exists then failwith "Sorry."
           else instance_exists := true
         ...
       end in
     mkobj

[2]

  foo.mli:
  --------

  class type t_myclass =
    object
      ....
    end

  val factory : unit -> t_myclass

  foo.ml:
  -------

  class type t_myclass =
    object
      ....
    end

  class myclass =
    object
      ....
    end

  let instance : t_myclass option ref = ref None

  let factory () =
    match !instance with
    | Some i -> i
    | None -> let i = new myclass in instance := Some i; i


> No, the proper way to do singletons in Ocaml is with modules, not objects.

But Brian is right, I'm sure.

-- 
Matt Gushee
Englewood, CO, USA

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Michael Wohlwend]

I think you can allways use Oo.copy to make a copy of an object. So if your 
singleton has mutable state you can create a  copy with Oo.copy and have two 
singletons ...
It seems modules are the way to go :-)

cheers,
 Michael

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[brogoff]

On Mon, 7 Nov 2005, Brian Hurt wrote:
> On Tue, 8 Nov 2005, skaller wrote:
>
> >>> The object oriented part of OCaml is roughly speaking
> >>> just as capable as that of Python, C++, Java, C# etc.
> >>
> >> Sure, I don't doubt that.
> >
> > I do. The Python system is much more 'capable' and much less 'robust'.
> > This is typical for dynamic typing vs static typing.
>
> I think I'm with Skaller here- Objects in Ocaml are much less powerfull
> than they are in (for example) Java or Python.

They're not "much less powerful" than they are in Java. They certainly lack
some features of the Java object system, but they posses many others. If
"powerful" means "supports multiple inheritance", Java is far less powerful.
If it means "supports" downcasting, ...

As far as static vs dynamic, dynamic type systems are inherently more
capable. There is no "slack" in a dynamically typed language. But the
possibility of a runtime exception is of course there.

>  For example, objects in
> Ocaml can not have non-virtual (non-overloadable) methods, or static
> (global) methods.  So patterns like singletons are hard to implement with
> Ocaml objects.
>
> But that's OK- because Ocaml provides other ways to provide those
> capabilities.  The problem I have with a lot of pure-OO languages is the
> need to make objects do everything.

The flip side of this is that OCaml is like Perl, with lots of ways to do
things, and many overlapping features. The fact that OCaml has classes and
modules is good, and that's how I think OO languages should be, but I would
expect that protection and hiding be done only by modules and not objects.

So, while I agree that a truly pure OO language is excessive, having a language
with tuples/records/variants/exceptions/... subsumed by the object system,
and a separate module system for namespace control is a reasonable approach.

> Ocaml is to use modules, not objects.  If you're not using the true power
> of objects- inheritance, virtual functions,

> and overloading-

Overloading is not an OO feature. Algol-68 and Ada 83, amongst others, had
overloading. While Java supports static overloading, languages like
CLOS and Dylan support generic functions with multiple dispatch, which
is far more powerful.

I do use classes when I want to reuse "record" field names, but that's
hardly OO. I suppose it is a kind of overloading though.

-- Brian

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Brian Hurt]

On Tue, 8 Nov 2005, brogoff wrote:

>> I think I'm with Skaller here- Objects in Ocaml are much less powerfull
>> than they are in (for example) Java or Python.
>
> They're not "much less powerful" than they are in Java. They certainly lack
> some features of the Java object system, but they posses many others. If
> "powerful" means "supports multiple inheritance", Java is far less powerful.
> If it means "supports" downcasting, ...

Also, the structural typing in Ocaml allows for some neat tricks that are 
basically impossible in Java.

I suppose it depends upon what you mean by "powerful" more or less.  I 
meant it in terms of "widely usefull".  Objects are usefull in Ocaml, but 
you can write large and very complex programs without them.  It's 
impossible to even write "hello, world" in Java without objects.

> As far as static vs dynamic, dynamic type systems are inherently more
> capable. There is no "slack" in a dynamically typed language. But the
> possibility of a runtime exception is of course there.

Yes.  For example, Ocaml will reject this code:
 	let f n =
 		if (n > 0) && (is_prime (2*n)) then
 			"bad idea"
 		else
 			false
 	;;

despite the fact that "bad idea" will never, ever be returned (given the 
obvious definition of is_prime, anyways).

But if we restrict ourselves to the domain of correct programs, now I'm 
not so sure.  Well, maybe, in the extreme fringes, there are correct 
programs which are being disallowed by the Ocaml type systems.  I've only 
been programming in Ocaml a couple of years now- I may just have not run 
across them yet.  But everything I've wanted to do in Ocaml I've been able 
to do, working with the type system and not against it.

> The flip side of this is that OCaml is like Perl, with lots of ways to do
> things, and many overlapping features. The fact that OCaml has classes and
> modules is good, and that's how I think OO languages should be, but I would
> expect that protection and hiding be done only by modules and not objects.

To my knowledge, they are.  How do you declare a private or protected 
method for a class variable *without* using modules to do so?

Brian

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[brogoff]

On Tue, 8 Nov 2005, Brian Hurt wrote:
> > As far as static vs dynamic, dynamic type systems are inherently more
> > capable. There is no "slack" in a dynamically typed language. But the
> > possibility of a runtime exception is of course there.
>
> But if we restrict ourselves to the domain of correct programs, now I'm
> not so sure.  Well, maybe, in the extreme fringes, there are correct
> programs which are being disallowed by the Ocaml type systems.

The canonical examples are those that involve polymorphic recursion (lots of
examples in Okasaki's Purely Functional data Structures book) and those
that involve flipping on the -rectypes compiler switch. Yes, there are
workarounds, but for the polymorphic recursion case, Haskell is nicer.

Yes, I realize I am nitpicking.

 I've only
> been programming in Ocaml a couple of years now- I may just have not run
> across them yet.  But everything I've wanted to do in Ocaml I've been able
> to do, working with the type system and not against it.
>
> > The flip side of this is that OCaml is like Perl, with lots of ways to do
> > things, and many overlapping features. The fact that OCaml has classes and
> > modules is good, and that's how I think OO languages should be, but I would
> > expect that protection and hiding be done only by modules and not objects.
>
> To my knowledge, they are.  How do you declare a private or protected
> method for a class variable *without* using modules to do so?

There are private methods in OCaml classes. I can imagine in other OO languages
that there would be none, and the privateness would be controlled by the module
system. It's only in 3.09 that we have private rows, which are a step in the
right direction.

-- Brian

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[skaller]

On Tue, 2005-11-08 at 16:04 -0600, Brian Hurt wrote:

> Yes.  For example, Ocaml will reject this code:
>  	let f n =
>  		if (n > 0) && (is_prime (2*n)) then
>  			"bad idea"
>  		else
>  			false
>  	;;
> 
> despite the fact that "bad idea" will never, ever be returned (given the 
> obvious definition of is_prime, anyways).

This is an interesting case, IMHO. A related case arose
in C++ and was discussed by the committee: something like:

	int x = 1/0;

The question was: is the compiler allowed to reject the program?

I believe the current answer is: IF the compiler can prove
that this code will necessarily be executed, then the behaviour
of the program is undefined anyhow, and so the compiler is allowed
to reject the program -- but it is NOT required to.

However, IF the compiler cannot prove the code will be executed,
then it must compile the program.

The interesting thing is that 1/0 is a 'constant expression'.
However this is not:

	int a = 0; int b = 1;
	int c = b/a;

In Felix, certain constructions are *required* to be optimised
at compile time. In particular,

	1/0

is a 'constant expression' and MUST be calculated at compile time.
However, as above, the compiler is not allowed to reject the program,
just because a constant expression cannot be calculated -- it has
to generate code that aborts the program or something, in case that
expression is never elaborated (this was a pain to get right,
and probably isn't yet)

In particular this is perfectly legal Felix:

	if true then 1 else 1/0 endif

and is REQUIRED to reduce to 1. Similarly:

	if true then 1 else "Hello" endif

is perfectly legal. The 'if/then/else/endif' construction
is being reused as a macro processing construction: there
is no type error here.

So .. it all depends on exactly how the language is specified.

BTW: I am not sure I like these preprocessor reduction rules.
The idea was to 'get rid' of #if style conditional compilation.
Without these kinds of rules, constant folding is effectively
impossible.

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

Re: Ant: [Caml-list] The "Objective" part of Objective Caml

[Florian Weimer]

>> > The object oriented part of OCaml is roughly speaking
>> > just as capable as that of Python, C++, Java, C# etc.
>> 
>> Sure, I don't doubt that. 
>
> I do. The Python system is much more 'capable' and much less 'robust'.
> This is typical for dynamic typing vs static typing.

The row type mechanism (or what it's called) allows me to write code
that can deal with objects of arbitrary classes, provided that they
implement the needed methods.  This comes quite close to what you can
do with more dynamic languages like Python, much closer than C++ or
Java.  (The GNU C++ compiler used to have "signatures", which were
quite similar, by the way, but you had to manually write down the
signatures, of course.)  Beyond that, the argument quickly turns into
the old "type checks at run time are more powerful" discussion.

Regarding my original question: In the meantime, I discovered the
paper "Objective ML: An effective object-oriented extension to ML" by
Rémy and Vouillon.  Curiously enough, I found a reference in Pierce's
TAPL book; search engines weren't helpful.  It seems to describe the
rationale behind the Objective Caml approach.  Since Brad Cox's work
is not mentioned, I think that any similarity is just a coincidence.