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

["Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>]

Brian Hurt <bhurt@spnz.org> writes:

> The general solution is to rethink the problem to avoid the downcast.

It's not always possible or desirable.

Example 1: exceptions. Fortunately OCaml provides an extensible exn
type. It's probably impossible to emulate using other features:
classes, polymorphic variants, modules etc., without Obj.magic.
OTOH dynamically typed or OO languages typically don't need extra
language features just to *represent* exceptions of extensible types.

Example 2: embedding a dynamically typed sublanguage in OCaml, with
extensible set of types of wrapped objects. For this I had to use
Obj.magic with manual tagging of dynamic types.

Attempts to avoid downcasts are often unmodular, they require to
specify all possible variants in one place.

>> Java now has generics (type parameters), and I assume that it has to get
>> around this situation somehow.
>
> If I understand it correctly, they basically lifted C++'s templates more 
> or less verbatim.

AFAIK the implementation technique is entirely different, similar to
parametric polymorphism in OCaml. It influences the semantics. You
can't select overloaded methods basing on a type substituted for a
type variable for example (except by using reflection at runtime);
you can do that in C++. There are no specializations of generics.
There are no types depending on types (an equivalent of putting
different typedefs in different specializations of a template).

Java generics compared to C++ templates are like OCaml parametric
polymorphism compared to OCaml modules.

> Downcasting is a sign you're doing something wrong.

I disagree. It may be, or not. Just that OCaml doesn't support
something doesn't imply that it must be evil.

> If you knew the object was a bar_t, why didn't it have the type
> bar_t from the get-go?

For the same reason as why can't exn be a regular algebraic type.

> If you don't know it's a bar_t, how do you know it's safe to cast it
> to a bar_t? Without RTTI, that is.

Of course something is necessary to determine at runtime whether it's
safe. I don't advocate unsafe constructs.

> By the way, RTTI costs memory (at least one extra word per object,
> plus the overhead of the Class classes for all types).

You could move the object header there. It would only make no room for
two bits for GC that OCaml uses, so it would be hard to adapt to OCaml
as it is, but it's not a significant overhead in general.

A dynamically typed language can have the overhead of one word per
object, for most objects. Only the size of arrays and strings is
stored after the header, but it would be a good idea anyway compared
to the current design - it would remove the artificial limit of object
sizes.

> Plus- does RTTI apply to non-objects? Ocaml has a lot of types that
> are not classes.

A possible answer: conceptually yes, physically it can be avoided for
unboxed ints or other unboxed variables whose type is known statically;
constants like the empty list can be boxed and allocated statically,
so they have almost the same overhead as currently (only the bit
pattern is not known until link time).

I don't claim that it would be easy to adapt to OCaml as it is.
I claim that it's not a bad idea in general.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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