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

[Brian Hurt <bhurt@spnz.org>]

On Tue, 21 Sep 2004, Michael Vanier wrote:

> Um, no, they didn't.  In fact, it's a completely different mechanism.  The
> compiler erases the generic information so that the JVM sees only old-style
> java classes without parameterization and adds casts where needed.  OK,
> this wasn't the greatest example in the world, because it relies massively
> on RTTI.

OK.  I'm not up on what precisely Java is doing here.  I note that they're 
also adding autoboxing/unboxing.

> I don't agree.  For instance, try implementing the equivalent of
> multimethods without some kind of downcast.  Of course, if a language
> supported multimethods from the get-go it would be even nicer, but very few
> languages do.  Now, if you're going to argue that wanting multimethods at
> all is a sign that you haven't thought through a problem carefully enough,
> we'll just have to agree to disagree.  I'm always suspicious of arguments
> that start off with "you really don't want to do that", because I can't say
> with any certainty what I will want to do or need to do 100% of the time.

Multimethods should use variant (tagged) types, not objects and 
downcasting.

For example, consider the case where I want to deal with a number, that 
could be an integer, a floating point number, or a complex (x + yi format) 
number.  I'd implement it like:

type number_t = 
    | Int of int
    | Float of float
    | Complex of float * float
;;

let add a b =
    match a, b with
        | Int(x), Int(y) 
        -> Int(x + y)
        
        | Int(x), Float(y) 
        | Float(y), Int(x)
        -> Float((float_of_int x) +. y)

        | Float(x), Float(y) -> Float(x +. y)

        | Int(x), Complex(yr, yi)
        | Complex(yr, yi), Float(x)
        -> Complex(((float_of_int x) +. yr), yi)

        | Float(x), Complex(yr, yi)
        | Complex(yr, yi), Float(x)
        -> Complex(x +. yr, yi)

        | Complex(xr, xi), Complex(yr, yi) ->
            Complex(xr +. yr, xi +. yi)
;;

This is what I meant by not everything in Ocaml needs to be objects.

Note that there is an advantage to how Ocaml does it- if you add a new tag 
to number_t, Ocaml will warn you in all the places you need to update to 
handle the new tag.


-- 
"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