Objective CAML syntax
Stphane Baubillier
I'm a new Objective CAML user, and after reading the online documentation, I
don't understand the need and/or the semantic of some syntatic choices and
expressions :
- Why self is not a keyword of the language ? (like this in C++)
- Why virtual methods are always abstract ? (in C++, you can define the
implementation of an abstract method, who can be called by the subclass)
- Why can't we define a parametrized method ? (i know that O'Lab try
this issue, but what is the reason ?)
- What is the need of "functionnal object" and is strane notation {< ...
>} ?
- What is the need of binary method concept ?
- What is the need of functor concept for modules ?
- Parameters place after de class name are for the constructor; but how
can we define multiple constructors ?
And, in general, CAML has a simple and easy reading syntax. Why Objective
CAML, for the object extension, has a complicated one ?
You can answer by comments or by links.
Thanks.
Stéphane Baubillier : baubi...@hotmail.com
Xavier Leroy
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/
Albert Y.C. Lai
> C++ Java OCaml
>
> non-virtual methods static methods functions
I am afraid static methods in Java correspond exactly to static
methods in C++.
--
[If you post a response, no need to cc me; if you cc me, please say so.]
A merchant gives you free samples of fish.
A friend teaches you how to fish.
Albert Y.C. Lai
> C++ Java OCaml
>
> non-virtual methods static methods functions
I am afraid static methods in Java correspond exactly to static
Stphane Baubillier
> > 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?
As described in O'Lab manual, an objective CAML extension, you have :
# class c = object method m x = x end;;
Some type variables are unbound in this type :
class c : object method m : 'a -> 'a end
The method m has type 'a -> 'a where 'a is unbound
You are obliged to write a polymorphic class;
In C++, you can write : template <class T> void m(T*); in a class definition
(for example, for defininig equality with another class).
Adam P. Jenkins
> 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
Not quite. I think this chart should be
C++ Java OCaml
functions N/A functions
static methods static methods N/A
non-virtual methods final methods(approx) N/A
virtual methods methods methods
pure virtual methods abstract methods virtual methods
Otherwise I think your answer was great.
--
Adam P. Jenkins
ajen...@netway.com
Gabriel Dos Reis
[...]
| C++ Java OCaml
|
| non-virtual methods static methods functions
^^^^^^
I guess you meant 'final'.
-- Gaby