Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
CamlIDL - stub code generator and COM binding for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1999-03-10 (12:14)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: CamlIDL - stub code generator and COM binding for OCaml
From: Xavier Leroy <>

> > 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 means "field a
> of field foo of x", or "field foo.a of x" ?

I am and more thinking that allowing labels in some types might be a
good solution.

Then one just has to write.

type foo = Foo of { a: int; b: int }
type goo = Goo of { a: char; b: char }

let x = Foo {a=1;b=2}
let y = Goo {a='a';b='b'}

With extraction, you just need to have pattern matched on the
record. The two following are ok:

fun (Foo {a=a}) -> a
fun (Foo x) -> x.a

and even, if we defined "a:" to be mutable in foo

fun (Foo x) -> x.a <- 3

The last ones may seem strange, but it is clearly unambiguous,
and if I remember correctly caml-light has already something like that
for mutable sum types.

This is an easy solution. If you are ready for something more
far-fetched, we could go for using type information, and use a
restricting scheme to keep principality, as is done in olabl for class
having polymorphic methods. This is safe and correct, and
syntactically very light. In fact, since exactly the same mechanism
would work, this would be very easy to add it to olabl.

Jacques Garrigue      Kyoto University     garrigue at
		<A HREF=>JG</A>