From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
To: Xavier.Leroy@inria.fr
Cc: caml-list@inria.fr
Subject: Re: CamlIDL - stub code generator and COM binding for OCaml
Date: Wed, 10 Mar 1999 18:43:56 +0900 [thread overview]
Message-ID: <19990310184356M.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Tue, 9 Mar 1999 17:07:20 +0100" <19990309170720.03713@pauillac.inria.fr>
From: Xavier Leroy <Xavier.Leroy@inria.fr>
> > 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" ?
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 kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
next prev parent reply other threads:[~1999-03-10 12:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-05 10:41 Xavier Leroy
1999-03-05 20:46 ` Andrew Martin
1999-03-08 9:41 ` Sven LUTHER
1999-03-09 16:07 ` Xavier Leroy
1999-03-09 18:54 ` Andrew Martin
1999-03-12 10:47 ` Thierry Bravier
1999-03-10 9:11 ` Pierre Weis
1999-03-10 9:43 ` Jacques GARRIGUE [this message]
1999-03-09 21:57 ` doligez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990310184356M.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=Xavier.Leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox