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 MAA32256; Fri, 15 Aug 2003 12:31:37 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA11113 for ; Fri, 15 Aug 2003 12:31:35 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h7FAVVT10009 for ; Fri, 15 Aug 2003 12:31:34 +0200 (MET DST) Received: from 203-219-16-100-syd-ts21-2600.tpgi.com.au (203-219-16-100-syd-ts21-2600.tpgi.com.au [203.219.16.100]) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h7FAV6728954; Fri, 15 Aug 2003 20:31:06 +1000 Subject: Re: [Caml-list] Obj.magic, Obj.t etc. From: skaller Reply-To: skaller@ozemail.com.au To: Jacques Garrigue Cc: Florian.Douetteau@ens.fr, caml-list@pauillac.inria.fr In-Reply-To: <20030814173444D.garrigue@kurims.kyoto-u.ac.jp> References: <20030814105551S.garrigue@kurims.kyoto-u.ac.jp> <002401c3623d$22c3f2e0$0201a8c0@foorama> <20030814173444D.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1060943466.22302.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 15 Aug 2003 20:31:09 +1000 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; ozemail:01 caml-list:01 jacques:01 florian:01 douetteau:01 neutralize:01 incompatible:01 unboxed:01 structs:01 pointers:01 dubious:01 descriptor:01 arrays:01 semantics:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2003-08-14 at 18:34, Jacques Garrigue wrote: > From: "Florian Douetteau" > Not so simple: it would also mean that all polymorphic functions on > arrays would create only boxed arrays, since their compile time > type is not float array. > As a result, the representation of float arrays would not be uniform, > requiring a check before access, which would probably neutralize any > performance advantage of having a special representation. > > Sure, this is an implementation problem. But not a simple one. > The only simple solution would be to have a special type for float > arrays, just like strings... highly incompatible. Actually the technology to solve this exists in C++ in the sense it supports specialisations, indeed, that is the *only* mechanism for polymorphism in C++ other than the C technique of void* .. which is the same as what most FP use with a bit of static type checking of the needed casting thrown in :-) The effect would be that you'd need to generate a switch in the exeuctable code, if and only if both boxed arrays and unboxed float arrays are used, and then only for routines where the type variable could be instantiated either way. As in C++, whole program analysis is needed, so the decision has to be deferred until link time. An important point though is that the run time system doesn't need any modification provided it can handle types (like float) or many C structs which can be bitwise copied (that is, don't contain any caml heap pointers). Heh..one of the things you find when considering expanded types is that most FP systems are based on a kludged type system -- the assumption is type values have a uniform representation and therefore you can have type variables (not just macro names in a meta language like in C++). In general, that assumption is wrong, which makes the type systems of dubious value. Its my guess that at least three kinds of type variables would be useful: (a) macros names (resolved at compile time) (b) pointers (known copy semantics) (c) arbitrary types Case (c) is easier to implement than you might think, since a type is almost completely characterised by a few functions (copy constructors, assignment operator, destructor .. etc). Indeed, the biggest problem seems to be *synthesising* new descriptor tables at run time. For example given that a copy constructor is a C function pointer, it isn't clear how to create a copy constructor for 'a * 'a Nevertheless it is clear an interpreter for some kind of easily synthesised bytecode could be written to solve this problem. ------------------- 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