From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA06823 for caml-redistribution; Tue, 27 Oct 1998 20:01:13 +0100 (MET) 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 PAA30426 for ; Mon, 26 Oct 1998 15:25:56 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA09574 for ; Mon, 26 Oct 1998 15:25:54 +0100 (MET) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Mon, 26 Oct 1998 06:25:53 -0800 Message-ID: <39ADCF833E74D111A2D700805F1951EF0B2EF58A@RED-MSG-06> From: Don Syme To: caml-list@inria.fr Subject: C interface and representation Date: Mon, 26 Oct 1998 06:25:49 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: weis I think we'd all agree that the O'Caml-C interface reveals rather a lot about the runtime layout of various O'Caml types. For example, it reveals that record types are represented as tuples. I'm wondering if the O'Caml compiler could emit a set of C macros that effectively hides these representation choices. For example, for a file foo.ml type abc = { flag1 : bool; flag2: bool; flag3: bool } ocamlc {some option} foo.ml > foo.h could generate C macros like #define Foo__abc__flag1(value) ... #define Foo__abc__flag2(value) ... #define Foo__abc__flag3(value) ... (where each of these are lvalues) This would, of course, make C code that creates and manipulates record valuables more robust, since it would be independent of the record ordering. I have a current application that creates record values with 10-20 fields (many of them boolean flags), and it is just silly to hardwire field numbers. Such records will probably be common in any interface to substantial APIs (I have in mind various Microsoft APIs). It may also be plausible for the compiler team to optimize the layout of records such as the one above at a later date. Any self respecting C programmer would expect the above record to consume 1 byte, and it would be nice to at least allow for the possibility of such optimizations, wouldn't it, without breaking C code? (Or, alternatively, to allow for a richer type representation description language that, for example, specified field widths) [ Actually, I've glossed over the fact that bits are not lvalues in C, so both "set" and "get" macros may be required. Also, marshalling and so on would be affected by such optimizations, but that's another story. ] Cheers, Don