From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA27753; Wed, 22 Sep 2004 00:21:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA30369 for ; Wed, 22 Sep 2004 00:21:25 +0200 (MET DST) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8LMLLQC020178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 22 Sep 2004 00:21:24 +0200 Received: from qrczak by qrnik.knm.org.pl with local (Exim 3.36 #1) id 1C9t0F-0005I0-00; Wed, 22 Sep 2004 00:20:51 +0200 To: Brian Hurt Cc: Michael Vanier , garrigue@kurims.kyoto-u.ac.jp, Subject: Re: [Caml-list] Re: OCAML Downcasting? X-Face: T0C?'>x8&TymF@` Ej6~H&|Uc2j{~CS,tTn|&?jC^xp+,k-6\@io3>5H5.L4GBdPptQ:pN`QJL$~2! References: From: "Marcin 'Qrczak' Kowalczyk" Mail-Followup-To: Brian Hurt , Michael Vanier , garrigue@kurims.kyoto-u.ac.jp, Date: Wed, 22 Sep 2004 00:20:51 +0200 In-Reply-To: (Brian Hurt's message of "Tue, 21 Sep 2004 16:38:25 -0500 (CDT)") Message-ID: <87isa76z7g.fsf@qrnik.zagroda> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at concorde with ID 4150A961.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 downcasting:01 marcin:01 'qrczak':01 kowalczyk:01 qrczak:01 downcast:01 extensible:01 dynamically:01 extensible:01 embedding:01 dynamically:01 sublanguage:01 tagging:01 downcasts:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Brian Hurt 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