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 KAA28082 for caml-redistribution; Wed, 10 Mar 1999 10:12:49 +0100 (MET)
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 RAA24871 for <caml-list@pauillac.inria.fr>; Tue, 9 Mar 1999 17:07:26 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA21576;
	Tue, 9 Mar 1999 17:07:20 +0100 (MET)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA30924; Tue, 9 Mar 1999 17:07:20 +0100 (MET)
Message-ID: <19990309170720.03713@pauillac.inria.fr>
Date: Tue, 9 Mar 1999 17:07:20 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Andrew Martin <amartin@ibmoto.com>, caml-list@inria.fr
Subject: Re: CamlIDL - stub code generator and COM binding for OCaml
References: <19990305114159.01952@pauillac.inria.fr> <36E042AB.32801982@ibmoto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <36E042AB.32801982@ibmoto.com>; from Andrew Martin on Fri, Mar 05, 1999 at 02:46:35PM -0600
Sender: weis

> I have one concern about the handling of structs. Actually, it's more of a
> concern with Ocaml than with idl, but idl makes the problem more apparent.
> 
> How can one deal with two struct types whose members have the same names.
> In Ocaml, for example:
> 
> type foo = {a:int; b:int}
> type goo ={a:char; b:char}
> 
> How can I now create an object of type foo?

Currently, you can't, and I agree this is a serious problem with
CamlIDL-generated code.  (There's also the symmetrical problem of how
do you now access the fields of an object of type foo.)

> It would be nice if I could write
> let x = ({a=4; b=5;}:foo) or
> let x = {foo.a=4; foo.b=4} or even
> let (x:foo) = {a=4; b=4}

Solutions 1 and 3 could be made to work by having a special type
inference rule for record construction when a known record type is
expected by the context.  OCaml already does a similar hack for
typing printf format strings.  However, it's a hack, and it has fairly
bad properties (e.g. the results of type inference become dependent on
the order in which the type-checker works.)

For access, you'd have to say something like (x : foo).a.

The second solution could be made to work for record construction, but is
syntactically ambiguous for field access: does x.foo.a means "field a
of field foo of x", or "field foo.a of x" ?

> However, if one is defining a caml interface for existing C code,
> the problem is much worse, since the C code will have been written
> without regard for the need to avoid reusing the same field name in
> different struct types.

Right.  The problem could also be attacked at the level of CamlIDL by,
for instance,

- adding an attribute "mlname" to struct fields to specify the name of
the label in the Caml code, e.g.

  struct s { [mlname(s_a) int a; [mlname(s_b)] int b; };
  struct u { [mlname(u_a) int a; [mlname(u_b)] int b; };

However, adding all those names becomes tedious.  Maybe CamlIDL could
use some heuristics to find suitably unique Caml label names
(e.g. if all struct field names are unique in the whole interface,
use them, otherwise prefix them by the struct or typedef name).

- putting sub-modules in the generated .ml and .mli files.
For instance, non-object interfaces in the IDL source could be
translated to sub-modules:

        interface I1 { struct s1 { int a; int b; }; }
        interface I2 { struct s2 { int a; int b; }; }

would become

        module I1: sig type struct_s1 = { a :int; b : int } end
        module I2: sig type struct_s2 = { a :int; b : int } end

Any other ideas?

- Xavier Leroy