Re: [Caml-list] Re: OCAML Downcasting?

[Brian Hurt <bhurt@spnz.org>]

On Wed, 22 Sep 2004, Marcin 'Qrczak' Kowalczyk wrote:

> Brian Hurt <bhurt@spnz.org> writes:
> 
> >> Apply this reasoning to the exn type. Why don't you define all exn
> >> constructors in one place?
> >
> > Ignoring the fact that exceptions are built into the language, I'd read
> > section 4.2 "Polymorphic Variants" of the Ocaml language manual for how to
> > get around this.
> 
> It helps only in some cases. In particular it's not expressive enough
> to replace exn.

No.  That's why exceptions were built into the language.

It does, however, allow you to 'retrofit' RTTI onto any type:

let do_stuff = function
    | `Foo of foo ->
        (* our argument is only of type foo, only do stuff we can
           do with a foo.
         *)
        foo#do_foo_stuff()
    | `Bar of bar ->
        (* In addition to being a foo, our argument is also a bar.
           Do foo stuff and bar stuff.
         *)
        bar#do_foo_stuff ();
        bar#do_bar_stuff ()
;;

As for interpreting a RTTI language, I do a full on interpreter.  I don't
try to use Ocaml as an intermediate language.  Every object gets a
StringMap ( = Map.Make(String)) to allow me to look up the member function
definition from the function name.  I collect the arguments up into
another StringMap (mapping from the name of the argument to the value),
and pass that it to any function I call.  Yes, you have to add the type 
information to every object, instead of having the compiler do it for you.

There is a whole long list of features Ocaml has that Java lacks, or 
requires you to use broken kludges to work around.  It sounds like- the 
better part of a decade later- they finally figured out that univeral 
types and being able to express types like 'int array list list' is a good 
thing.  Partial function application still has to be kludged with "doit" 
objects- objects and interfaces with single member functions- the "doit" 
function.  And so on, and so forth.  

The trick is, when programming in Java, to "think in Java", not in Ocaml
(or C).  Likewise, the trick is, when programming in Ocaml, to think in
Ocaml.  The question is not "how do I make this particular Java solution
to the problem work?"  The question is "how do I solve this problem in
Ocaml?"

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners