Duplicate functionality?

Duplicate functionality?

[Stephen Brackin]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

I've had extensive programming experience with C/Lex/Yacc/SML, some user's
exposure to the SML module system, and a little Java programming experience,
but I'm new to OCaml and didn't follow the OCaml Introduction's Objects
subtleties.  Would people please recommend documents, preferably on-line,
that would explain the issues and intended uses for me?

 

My biggest initial question is why OCaml has both a modules system and
objects: Aren't they different ways of accomplishing the same things?

 

Steve


[-- Attachment #2: Type: text/html, Size: 2316 bytes --]

Re: [Caml-list] Duplicate functionality?

[Jon Harrop]

On Saturday 22 October 2005 02:04, Stephen Brackin wrote:
> My biggest initial question is why OCaml has both a modules system and
> objects: Aren't they different ways of accomplishing the same things?

Both modules and objects allow you to encapsulate related definitions, yes.

However, modules are much more static by nature and objects are much more 
dynamic, i.e. you get stronger static checking using modules than you do 
using objects, giving more comprehensible error messages and more robust and 
faster code.

Consequently, OCaml programmers tend to prefer modules over objects where 
possible.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Duplicate functionality?

[Matt Gushee]

Jon Harrop wrote:

>> On Saturday 22 October 2005 02:04, Stephen Brackin wrote:
>>
>
>>>>My biggest initial question is why OCaml has both a modules system and
>>>>objects: Aren't they different ways of accomplishing the same things?
>
>>
>> Both modules and objects allow you to encapsulate related
definitions, yes.
>>
>> However, modules are much more static by nature and objects are much
more
>> dynamic, i.e. you get stronger static checking using modules than you do
>> using objects, giving more comprehensible error messages and more
robust and
>> faster code.


That's certainly true ... I've probably spent twice as much time
debugging type errors in mutually recursive objects as I have on all
other kinds of errors put together.

On the other hand (as Jon's statement implies), it's much easier to
write extensible code with objects. When you call a function on a module
(except within a functor) you are using a specific implementation,
whereas you can call an object method, say foo#display (), where foo can
be any object with a 'display' method that matches the expected type.

And even if modules and objects were functionally equivalent, I think
one of the great things about OCaml is the freedom it gives you to
structure your application in the best way for the problem.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Duplicate functionality?

[Gerd Stolpmann]

Am Samstag, den 22.10.2005, 04:31 +0100 schrieb Jon Harrop:
> Consequently, OCaml programmers tend to prefer modules over objects where 
> possible.

Once you get accustomed to the class system, which is definitely more
complicated than the module system, this is no longer true. I'm the
counterexample of your thesis.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------

Re: [Caml-list] Duplicate functionality?

[Jacques Garrigue]

From: "Stephen Brackin" <stephen.brackin@verizon.net>

> My biggest initial question is why OCaml has both a modules system and
> objects: Aren't they different ways of accomplishing the same things?

I'm not aware of any detailed comparison between objects and modules
in ocaml. However I'll try to give my thoughts on that.

Both modules and object have multiple roles, and they only overlap
for some.
For instance, modules offer some kind of namespace management, which
objects do not. This is different from Java which has no modules, and
where classes have a role in namespace management.
Similarly object subtyping allows the creation of heterogeneous
collections of values, which is impossible with modules.

Another specificity of objects is their extensibility through
inheritance, with late binding (i.e. components can depend on each
other.) You can try to do this with functors and recursive modules,
but this quickly becomes rather heavy-weight.

The real overlap between the two concepts is in their ability to
create collections of methods, and to have parameterized constructors
(functors for modules). 
Indeed, apart of the capacity to hide types, one could argue that
objects alone can encode the whole module system, thanks to
polymorphic methods. Practice shows that it ends up being rather
clumsy: type parameters can only be expressed by type variables, which
do not behave exactly like type constructors.  Moreover object typing
relies strongly on type inference, which can cause confusing error
messages.
Encoding objects into modules, as abstract data types, generally works
well, but you lose object subtyping, and you must specify the module
name for each method call (a light burden in general, but not so nice
when using functors, and you end up with lots of module names around.)

So yes, one could say that objects and modules provide different ways
to do some similar things. This is particularly true for simple data
structures like stacks or queues: there is no good reason to use one
approach over the other.
In practice they provide very different tradeoffs between flexibility
and robustness. Modules are extremely robust, in that you are so
explicit that the origin of any problem should be immediately
clear. But this also means more verbosity, and some difficulties in
reuse: you may have to parameterize on more modules than you
would like to.  On the other hand objects let you pass your
implementation around with your data, making things much simpler at
first. But their typing being more brittle, it can hurt when something
goes wrong.

Since one uses ML mostly for robustness, I suppose that when there is
no explicit need for subtyping or late-binding, the natural way to go
is modules. But when they become so verbose as to be cumbersome, and
the underlying model is object-oriented, objects may be more
comfortable. 
Both approaches expose their weaknesses when pattern-matching is
involved: this essential feature of functional programming doesn't
like any form of abstraction.

By the way, I believe there is one further hurdle when using objects:
their definitions are not compositional. That is, a module is just a
collection of functions, which can exist themselves independently from
one another (yet not independently of type defintions), but methods
are not just functions (for instance you cannot pass the complete self to
a function), and they cannot exist independently from objects. This
makes harder the transition from the core language, where one usually
starts writing, to the object language, where one might want to move.

Jacques Garrigue

Re: [Caml-list] Duplicate functionality?

[Lauri Alanko]

On Sat, Oct 22, 2005 at 02:49:16PM +0900, Jacques Garrigue wrote:
> I'm not aware of any detailed comparison between objects and modules
> in ocaml.

The slides from Xavier Leroy's talk at ICFP '99 might at least be useful
to the original poster:

http://pauillac.inria.fr/~xleroy/talks/icfp99.ps.gz


Lauri

Re: [Caml-list] Duplicate functionality?

[Brian Hurt]

On Fri, 21 Oct 2005, Stephen Brackin wrote:

> My biggest initial question is why OCaml has both a modules system and
> objects: Aren't they different ways of accomplishing the same things?

No.  And this is one of the most misunderstood things about Ocaml modules- 
that they are NOT just a weird and broken implementation of objects.  A 
better point of reference would probably be C++ templates (although Ocaml 
modules fix the complaints I have with C++ templates).

Modules are used for code that is "based on" other code.  An example makes 
this clearer.  Let's consider Newton's method for root find.  This is an 
incredibly powerfull algorithm that can be applied to a huge number of 
different number systems.  For example, it works on reals, it works on 
complexs, it works on quaterions, it works on integers, and it works on 
systems of non-linear equations (vectors and matricies).  And when I say 
it works on reals, I mean it works on all representations of reals- it 
works on IEEE floating point, it works on arbitrary precision rationals, 
it works on arbitrary precision floats, it works on fixed precision 
floats, etc.

All we need to implement Newton's method is a small set of basic 
operations.  We need subtraction, we need to be able to solve Ax = b given 
A and b (which is just x = b/A in most number systems, but we express it 
this way as it's more "natural" if A is the Jacobian matrix of partial 
derivitives and b is the vector residual), and we need some way to say 
we're "close enough" to the solution that we can stop.

With modules, we might write:

module type Req = sig
     type t (* the basic type of the number system *)
     type dt (* the type of derivitives- generally, this will be the same
              * as t, but in the case of vectors/matricies, t is a vector
              * while dt is a matrix.
              *)
     type et (* The type of the error value.  Often times this will be
              * the same as t above, but for "constructed" types
              * like complexes and vectors, type et will be whatever
              * real type they are made out of.
              *)
     val sub : t -> t -> t (* subtraction *)
     val solve : et -> dt -> t -> t (* Solve Ax = b to within epsilon.
                                     * Generally epsilon will be ignored,
                                     * and the solution will just be
                                     * x = b/A.
                                     *)
     val default_epsilon : et
     val within_epsilon : et -> t -> t -> bool
         (* Returns true if the two value differ by a factor of less
          * than epsilon.
          *)
end;;

module Make(Alg: Req) = struct

     exception Max_iters_reached of Alg.t

     let meth ?(epsilon = Alg.default_epsilon) ?(max_iters = max_int)
         f df x
     =
         (* Find a root to f given f and it's derivitive df starting
          * at an initial guess of x.
          *)
         let rec loop i x =
             if i > max_iters then
                 raise (Max_iters_reached x)
             else
                 let x' = Alg.sub x (Alg.solve epsilon (df x) (f x)) in
                 if Alg.within_epsilon epsilon x x' then
                     x'
                 else
                     loop (i+1) x'
         in
         loop 0 x
end;;

Now, we could probably implement something like this in objects- Newtons 
would be a base class calling out to virtual functions like solve and sub 
which would be implemented in concrete subclasses.  But there are several 
large advantages to using modules in this case.

The first one is types.  Note that were I to implement Newtons with 
floating point numbers, like:

module Float = struct
     type t = float
     type dt = float
     type et = float
     let sub = ( -. )
     let solve (_: et) a b = b /. a
 	let default_epsilon = 1.e-14;;
 	let within_epsilon e x y =
         ((abs_float ((x -. y) /. x)) < e) || ((abs_float (x -. y)) < e)
end;;

module FloatNewtons = Make(Float);;

Ocaml figures out the t, dt, and et are "all the same type", and I have a 
function with the right signature.  This is doable with dynamic type 
checking and objects, but not static.  Or at least I've never seen it done 
in a static language.

Another advantage of modules over structures in the type arena is to be 
able to express the "these two objects need to be of the same 
implementation" as a type constraint.  An example of this is the compare 
function in Map or Set.  The compare function wants to gaurentee that the 
two maps or sets you are comparing have the same ordering.  They can do 
that using modules and functors.

Another advantage of modules and functors is, with ocamldefun, the ability 
to remove the layer of vituralization, and actually have myself a 
high-performance Newton's method implementation.

Another advantage is that it allows objects to be objects, and stop having 
to be things they're not, like name spaces.  Ocaml objects have a hard 
time implementing the Singleton pattern, for example.  Of course they do- 
you should be using modules for that.

Brian

Ant: [Caml-list] Duplicate functionality?

[Martin Chabr]

There have alrady been some excellent answers to your
question up to now, but I would still like to draw
your attention to the O'Reilly book on OCaml by
Emmanuel Chailloux, Pascal Manoury and Bruno Pagano.
The english translation is available for free on the
Web. The book uses both the module and the object
approach and compares them as well:
http://caml.inria.fr/pub/docs/oreilly-book/

Another document which describes both is the
Introduction to OCaml by Jason Hickey, obtainable as a
pdf on the web as well:
http://www.nuprl.org/documents/Hickey/02caltech-ocaml.html

I hope this helps.

Martin

--- Stephen Brackin <stephen.brackin@verizon.net>
schrieb:

> I've had extensive programming experience with
> C/Lex/Yacc/SML, some user's
> exposure to the SML module system, and a little Java
> programming experience,
> but I'm new to OCaml and didn't follow the OCaml
> Introduction's Objects
> subtleties.  Would people please recommend
> documents, preferably on-line,
> that would explain the issues and intended uses for
> me?
> 
>  
> 
> My biggest initial question is why OCaml has both a
> modules system and
> objects: Aren't they different ways of accomplishing
> the same things?
> 
>  
> 
> Steve
> 
> > _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



	

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

Re: Ant: [Caml-list] Duplicate functionality?

[Didier Remy]

And also

        http://pauillac.inria.fr/~remy/cours/appsem/
        http://pauillac.inria.fr/~remy/cours/appsem/ocaml-mixins.html

or...

http://caml.inria.fr//cgi-bin/search.en.cgi?words=overlapping+objects+modules

    Didier