Objective CAML syntax - comp.lang.functional

Message from discussion Objective CAML syntax

Xavier Leroy

View profile

More options Jul 12 1999, 3:00 am

Newsgroups: comp.lang.ml, comp.lang.functional

Followup-To: comp.lang.ml

From: Xavier.Le...@see.my.sig.for.address (Xavier Leroy)

Date: 1999/07/12

Subject: Re: Objective CAML syntax

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

Wow, that's a lot of questions. Let me try to answer them constructively
(i.e. not by "because OCaml is not C++").

> - Why self is not a keyword of the language ? (like this in C++)

I remember discussing this with the designers of the object part of
OCaml, Jérôme Vouillon and Didier Rémy. The arguments in favor of not
having "self" as a keywords were 1- this makes one fewer reserved
identifier, 2- you can call the self argument "self" or "this"
depending on whether you come from a Smalltalk or C++/Java background,
and 3- the ability to rename the self argument like you'd rename the
parameter of a function comes in handy for giving a reduction
semantics to the language.

> - Why virtual methods are always abstract ? (in C++, you can define the
> implementation of an abstract method, who can be called by the subclass)

I detect a possible keyword confusion here. Methods in OCaml are
always "virtual" in the C++ sense: they can always be overriden in
subclasses and are always subject to dynamic dispatch and are always
subject to dynamic dispatch at method invocation time. The "virtual"
keyword in OCaml denotes what is called "pure virtual" methods in C++
or "abstract" methods in Java: the method is just declared but no
implementation of the method is provided, leaving the actual
implementation to the subclasses. The following chart should clear
potential misunderstandings:

C++ Java OCaml

non-virtual methods static methods functions
virtual methods methods methods
pure virtual methods abstract methods virtual methods

> - Why can't we define a parametrized method ? (i know that O'Lab try
> this issue, but what is the reason ?)

I don't understand the question. Methods can take (value) parameters:

method f x y = x + y

In addition, classes can also be parameterized by initialization
values as well as by types. What other kind of parameterization do
you have in mind?

> - What is the need of "functionnal object" and is strane notation {< ...
> >} ?

In OCaml, data structures come in two flavors: immutable and mutable.
Immutable structures correspond to a so-called "functional"
programming style where you rebuild data structures as needed.
Mutable structures correspond to an "imperative" programming style
where data structures are modified in place. The "functional" style
has definite advantages in terms of software reliability, ease of
formal specification, and ability to share sub-structures safely.

It is true that most OO languages make object fields mutable by
default. However, OCaml also supports immutable object fields, which
you use in a functional style by copying them when you need to change
a field.

To the best of my knowledge, no mainstream OO language supports
functional updates as per OCaml's {< ... >} construct. However, some
of them (e.g. Java) support a built-in "clone" operation, that returns
a shallow copy of the given object. As a first approximation, you can
view {< ... >} as a cloning operation followed by one or several field
updates.

> - What is the need of binary method concept ?

It's a standard programming trick in class-based OO languages. In
those languages, you attach operations to objects. If your operation
naturally operates on two or more objects (e.g. equality), you must
attach the operation to one of the objects and pass the others as
parameters to the method. If you look at the Java API, for instance,
you'll see plenty of binary methods, e.g. "equals" in java.lang.Object.

Binary methods raise many hairy typing problems, requiring either
large amounts of dynamic downcasts (as in Java) or a fairly
sophisticated static type system (as in OCaml). In my opinion, binary
methods is where class-based OO languages hit their limits and where
languages based on multi-methods start to shine. But still, that's a
programming idiom common enough that the OCaml designers felt
compelled to support it.

> - What is the need of functor concept for modules ?

Functors are modules parameterized by modules. They allow you to have
a module A that you can connect both to a module B and another module B'
(implementing differently the same interface) in the same program.

One common use of functors is as a mass parameterization mechanism.
Assume you have 10 functions that are all parameterized by the same 5
functions. You could write those 10 functions as higher-order
functions, taking the 5 functions as parameters. But then you'd have
to pass those 5 functions as arguments over and over again; even with
partial applications, we're talking about at least 10 partial
applications. With a functor, you can group the 5 parameters into one
structure and the 10 functions into another structure parameterized by
the first structure, and one functor application will do all the
plumbing at once.

Another common use of functors is to represent parameterized abstract
data types (i.e. abstract data types + operations on those types).
Functors allow you to parameterize one A.D.T. (one type + operations)
not just by one type, like regular ML polymorphism does, but by one
A.D.T. (one type + its operations). The difference is subtle, but
lead to stronger and safer static type-checking in the case of
functors. You may want to ponder the example of sets (viewed as a
functor over ordered types) in the OCaml tutorial to see what I mean
here.

For more examples of functors, see Robert Harper's course notes on SML,
or Mads Tofte's "Four Lectures on Standard ML".

> - Parameters place after de class name are for the constructor;
> but how can we define multiple constructors ?

Good question. In OCaml 2.00 and up, the class language lets you
express this as partial application of classes. Assume for instance
that you're defining a class of hash tables parameterized by the
initial size of the table:

class hashtable size =
object
method put key value = ...
method get key = ...
...
end

To provide a "constructor" with a default size of 10, you'd just do:

class hashtable_with_default_size = hashtable 10

Then, in your program,

new hashtable_with_default_size

gives you a hashtable of size 10, and

new hashtable 123

gives you one with size 123. While it may look like both hash tables
come from "different" classes, this is not really so: they have
compatible types and exactly the same methods, so they really behave
like if they came from the same class.

> And, in general, CAML has a simple and easy reading syntax. Why Objective
> CAML, for the object extension, has a complicated one ?

Not everyone will agree with you here. For instance, there seems to
be a popular conception these days that any syntax that is not based
on braces suck, period.

To me, the object part of OCaml has a richer and more complex syntax
than the core OCaml language just because class-based OO programming
is inherently complex -- much more so than the sugared lambda-calculus
that is at the basis of core ML. There are many different notions
involved, and this reflects in the concrete syntax.

Anoter reason is that the core OCaml language is at least 15 years
old, and thus we've had plenty of time for polishing or getting used
to its syntax, the OO part of Ocaml is quite recent and is the first
attempt at integrating a complete OO language into ML, so some rough
edges remain. Also, we wanted to keep the core language syntax
(almost) unchanged for backward compatibility, and this imposed a lot
of additional constraints on the concrete syntax.

Hope this answers your (numerous) questions.

- Xavier Leroy
--
Valid e-mail address (without the underscores): Xavier.Leroy@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/

Reply to author Forward