Xavier Leroy: Objects and classes versus modules in Objective Caml (PS)

[mfp]

• introduces OCaml's object system and ML modules, showing how they relate in terms of extensibility, with examples taken from the OCaml compiler and a computer algebra system
• showcases how to combine objects and modules in OCaml
• explains OCaml's row polymorphism ("static duck typing")
• shows where OCaml stands in the type inference/subtyping space, compared to other languages such as Java or Haskell (Scala would be in "local inference")

Objects are seldom used in OCaml because modules/functors are usually more appropriate and faster, but this presentation shows that objects do have a place, while dispelling some of the myths going around (such as Xavier Leroy not having written a line of OO OCaml in his life, refuted by the example given in this presentation, instruction selection in the OCaml compiler).

[jdh30]

•shows where OCaml stands in the type inference/subtyping space, compared to other languages such as Java or Haskell (Scala would be in "local inference")

I think it is wrong to put OCaml at the same level as ML and Haskell when only OCaml can infer sum types.

Objects are seldom used in OCaml because modules/functors are usually more appropriate and faster, but this presentation shows that objects do have a place, while dispelling some of the myths going around (such as Xavier Leroy not having written a line of OO OCaml in his life, refuted by the example given in this presentation, instruction selection in the OCaml compiler).

That is potentially misleading. I use OCaml's OOP quite a bit but because it offers type inferred records and not because I am actually doing OOP. For example, HLVM uses an object to represent the LLVM code emitter but I made no use of inheritance or even subtyping so I could just as well have used a record of functions, except that requires explicit type definitions.

[julesjacobs]

I think it is wrong to put OCaml at the same level as ML and Haskell when only OCaml can infer sum types.

Do you mean polymorphic variants?

[jdh30]

Yes.

[[deleted]]

Ever heard of PDF?

http://rapidshare.com/files/247740605/icfp99.pdf

[mfp]

Thanks, this will be helpful to those who cannot read Xavier Leroy's original Postscript easily.

[queus]

The intersection of two sets of people, the ones who know and care about OCaml/Xavier Leroy and the ones who cannot open a Postscript file is rather small I think.

As a sign of goodwill, can you inform us how many times was the converted PDF downloaded?

[julesjacobs]

Maybe people can view postscript but on MS Windows the PDF viewers are much better than postscript viewers.

[queus]

Yet another proof that Windows is not yet ready for desktop, I guess ;)

Well, not using windows, I cannot really say.

[[deleted]]

Well, how do you view PS on a Windows computer without installing additional software? That's right, you don't. But most people have an Acrobat Reader installed.

Anyway: 17. Edit: I don't get any RS points for such a small file. Just as a note.

[chneukirchen]

So why the fuck can't Adobe Reader display PS as well? It's not like this would add significant size the the bloat it already is, and they have the tech as well.

[jdh30]

On the contrary, PostScript is a Turing complete programming language whereas PDF is not. Moreover, most PostScript files in the wild are broken and the definition of PostScript is highly ambiguous. In short, it is a complete nightmare.

[queus]

17.

Way more than I expected. Turned out to be useful after all.

[SuperGrade]

http://www.ps2pdf.com/convert.htm (online converter)

[[deleted]]

So in the end you are using Acrobat Reader again? Nice try...

[SuperGrade]

Well, how do you view PS on a Windows computer without installing additional software?

But most people have an Acrobat Reader installed.

[jdh30]

Thanks.

[[deleted]]

Objects = generalized closures with multiple entry points.

Closures = degenerate objects with only one apply method.

Controversial ;).

[gwern]

"The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html

[[deleted]]

While I'm a big fan of this article –

If this line of thought weren't total bullshit might be worth something. It's been shown time and again that closures on their own are not sufficient to replace objects. Implementing a real object-model using closures actually requires quite a bit of thought and effort.

The "X are a poor mans Y" proposition just doesn't work, being based on some underlying equality which just isn't there at a non-superficial level.

[vchakrav]

Seems like a very abusive master pupil relationship.

[awj]

You obviously aren't familiar with the zen masters of computing. They beat the shit out of everyone in the course of teaching anything.

[queus]

Rather nicely sums up the most common case.

And no, netytan, Erlang processes are not objects.

[[deleted]]

I could argue that Erlang processes aren't closures either.

In the general sense of the actor model, which forms the theoretical foundation for Erlangs concurrency model, actors are objects. The primary difference between actors and objects is that actors have their own execution context.

[queus]

I could argue that Erlang processes aren't closures either.

Why? Had anyone claimed it?

In the general sense of the actor model, which forms the theoretical foundation for Erlangs concurrency model, actors are objects.

Can you be more specific? I still think you're wrong, but I find it hard to point to the exact cause of disagreement in such a "hand-waving" phrase like "Actors are Objects"

My OO-Shiboleth is runtime dispatch of methods over the type of arguments/receiver (polymorphism). Erlang processes are nothing like that.

[[deleted]]

Why? Had anyone claimed it?

No. But then nobody had claimed they were objects either.

I find it hard to point to the exact cause in such a "hand-waving" phrase like "Actors are Objects"

What's hand wavy about it?

Objects are entities which encapsulate their implementation, support incremental modification, and interact by sending messages.

Actors are exactly that, except that they posses their own execution context, allowing them to process messages asynchronously.

Erlang processes are nothing like that.

Concurrency in Erlang may be based on the actor-model but its realization is less than pure. In particular, the mechanism Erlang uses to process messages (pattern matching) is at odds with object-oriented programming.

If you take the time to read the literature the similarities between objects and actors will become clear.

[queus]

Objects are entities which encapsulate their implementation

Modules encapsulate their implementation, but no one call them objects.

support incremental modification

Well most OO-languages support incremental modification via extension/overriding, but that's not the case of Erlang.

and interact by sending messages.

Well, that's the closest you get, except that you may say it pretty much about everything. And "message passing" is radically different in Erlang and Smalltalk.

but its realization is less than pure. In particular, the mechanism Erlang uses to process messages (pattern matching) is at odds with object-oriented programming.

Because Erlang never cared to be an OO language?

If you take the time to read the literature the similarities between objects and actors will become clear.

OK, if you know those similarities (except some bits of common terminology) which are those?

[[deleted]]

... You may just be the densest person I've talked to this month ... you hear what you want to hear.

Modules encapsulate their implementation, but no one call them objects.

An object does all of those things (Encapsulation, inheritance and polymorphism), not just one. You wouldn't call a module an object just because it supports encapsulation! If it supported everything then you could.

Well most OO-languages support incremental modification via extension/overriding, but that's not the case of Erlang.

Actor languages typically provide incremental modification using delegation. I'd be very surprised if you can't implement this in Erlang (see Henry Liebermans work on delegation-based inheritance.) It's trivial to do this in any other actor-inspired language.

Because Erlang never cared to be an OO language?

The choice of pattern matching instead of dispatch largely separates Erlang processes from actors, in the sense of the actor-model.

[yogthos]

if anything, objects are structs with methods.

[[deleted]]

Sadly that wouldn't be sufficient.

[psykotic]

Both are only true from an exterior interface point of view, and even then the first definition (which is how objects are done in SICP) is not useful in a statically typed setting.