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 9B8733E837 for ; Thu, 31 Aug 2006 09:15:53 +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 k7V7Fp6M009387 for ; Thu, 31 Aug 2006 09:15:52 +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 k7V7FjGD023102; Thu, 31 Aug 2006 16:45:45 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Class/prototype-based OO From: skaller To: Jacques Garrigue Cc: caml-list@inria.fr In-Reply-To: <20060831.153607.06273444.garrigue@math.nagoya-u.ac.jp> References: <20060831.101146.29126305.garrigue@math.nagoya-u.ac.jp> <1157001502.6555.12.camel@rosella.wigram> <20060831.153607.06273444.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Date: Thu, 31 Aug 2006 17:15:45 +1000 Message-Id: <1157008545.6555.116.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44F68CA7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; lexically:01 variants:01 debugger:01 debugger:01 rtti:01 debugging:01 rtti:01 abstraction:01 debugging:01 abbreviation:01 abstraction:01 compilers:01 statically:01 casts:01 confines:01 On Thu, 2006-08-31 at 15:36 +0900, Jacques Garrigue wrote: > From: skaller > > 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". > > Here you have to read between lines :-) Spying between the cracks between the boards whilst ROFL? > I am a user of the debugger, and I also use objects at times, so I > have a personal interest in having better support for objects in the > debugger, through RTTI for instance. But this would be quite a bit of > work, .. especially in the native code system .. > so this is difficult to justify if I'm the only user. Hence the > above wording... > If you think of it, debugging contains all the difficulties of RTTI, > but without the justification for _not_ having it, that is, you clearly > want to break abstraction when debugging. Good point. > So that to do things > properly, we would even want to now dynamic type information about > polymorphic types, which is even harder than for objects. It is my guess (and only a guess!) that there is a balance between run time checks and compile time checks. Typing is always an abbreviation (abstraction) and sometimes stronger or weaker than desired: for example array bounds checks at run time, because the type system doesn't cope with array sizes as part of the type. All compilers do this. Some delegate a lot more to run time than others eg Java: I pick Java because contrary to popular opinion it is basically a dynamically typed language, with a bit of static typing thrown in for a few scalar types :) C++ tends to err the other way: it is basically statically typed, with exceptions and casts using RTTI. Plus of course in *all* cases programmers spend a lot of time implementing their own application specific kind of run time typing .. because in some sense that is what a program does: there is no clear boundary between the concept of 'type' and 'data'. The real issue here is surely how to do dynamic typing systematically and coherently *within* the confines of static typing regime. The most interesting recent example I've seen of this is in Alain's XDuce stuff, where 'regular expression' actually becomes a type not a data structure. In this case, programmer want so often to play with XML and keep repeating the same run time coding patterns, it is worthwhile enriching their environment with a typing regime based on those patterns. This is a very beautiful piece of work! -- John Skaller Felix, successor to C++: http://felix.sf.net