From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 036527E4B for ; Thu, 31 Aug 2006 07:18:39 +0200 (CEST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7V5Iacr021650 for ; Thu, 31 Aug 2006 07:18:38 +0200 Received: from rosella (ppp14-47.lns2.syd7.internode.on.net [59.167.14.47]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k7V5IMGv037749; Thu, 31 Aug 2006 14:48:23 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Class/prototype-based OO From: skaller To: Jacques Garrigue Cc: kremenek@cs.stanford.edu, caml-list@inria.fr In-Reply-To: <20060831.101146.29126305.garrigue@math.nagoya-u.ac.jp> References: <53c655920608250051x48d81cbagabf8039f0269beee@mail.gmail.com> <1156505490.20759.354.camel@rosella.wigram> <20060831.101146.29126305.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Date: Thu, 31 Aug 2006 15:18:21 +1000 Message-Id: <1157001502.6555.12.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44F6712C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; compiler:01 abstraction:01 ocaml:01 downcasts:01 rtti:01 downcasting:01 rtti:01 debugger:01 lexically:01 variants:01 2006:98 sourceforge:01 wrote:01 typing:01 typing:01 On Thu, 2006-08-31 at 10:11 +0900, Jacques Garrigue wrote: > From: Ted Kremenek > Since this approach does not modify the compiler, or use any unsafe > feature, it does not break abstraction in any way. If you re-read that claim .. you can see that Ocaml is used for something *other* than programming. It is used to *prove* the safety of a technique. Such high level reasoning is only possible because of the rigid adherence to type safety. The difference between Jacques 'Hashtable' for downcasts and system generated RTTI is that the latter would have to be enshrined in the type system, whereas the former, whilst potentially performing the same function if used systematically, exhibits its own typing within the type system. So in fact, as is typical of advanced languages, one could make a claim for the addition of some feature, by demonstrating it can be done already as sugar .. the demonstration then proves safety and inspires the implementation .. and in particular the typing of it. Most interestingly here .. with campl4 as a standard tool you can do quite a bit of such sugaring yourself! > Independently of downcasting, RTTI would also be needed for providing > more information in the debugger. But there seems not to be much > demand for that. I would note it is difficult to judge the utility of a missing feature :) Try to tell someone in the C++ community that C++ is severely constrained because it doesn't have first class lexically scoped functions, variants, or pattern matching .. even if you explain what they are they'll just say "Oh, we can do that this way .. but don't have much call for it". -- John Skaller Felix, successor to C++: http://felix.sf.net