Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Edgar Friendly <thelema314@gmail.com>
To: Brighten Godfrey <pbg@cs.berkeley.edu>
Cc: Jon Harrop <jon@ffconsultancy.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Record field label locality
Date: Wed, 13 Aug 2008 07:48:52 -0500	[thread overview]
Message-ID: <48A2D834.5020508@gmail.com> (raw)
In-Reply-To: <735BE8E5-2CCB-41FA-87E7-8E4027966048@cs.berkeley.edu>

Brighten Godfrey wrote:
> Two things come to mind:
> 
> (1) The type of get_f1 is handled analogously to the way it is handled
> for objects, something like this:
> 
>     val get_f1 : < x : 'a; .. > -> 'a = <fun>
> 
> I'm guessing that if you did this, you would have to "instantiate"
> `get_f1' each time it is applied to a new record type, which I assume is
> inconvenient (or not?).
> 
Yes - this breaks separate compilation.

> (2) Require that all record field accesses refer to a globally-unique
> record type, making conversion to a record field index is easy.  So the
> example code Edgar gave would result in a compilation error because the
> compiler cannot determine which `.f1' field the access refers to.  But
> consider this code:
> 
>     let return_garlic () =
>         let x = {M2.f2=5; M2.f1="garlic"} in
>         x.f1
> 
> In line 2, globally unique record field names are given, which allows
> the compiler to tag variable `x' with type `M2.t2'.  Then in line 3, the
> record field access `x.f1' can only mean `x.M2.f1'.
> 
In this situation, the type information influences what code is
generated.  The OCaml developers have been as careful as possible to
avoid this.  The typing stage of compilation acts as a filter to
eliminate incorrect programs, and that's it.

I've had my share of ideas of how typing information could usefully
connect with code generation, but have been shut down because the ocaml
developers (probably rightly) don't want to bridge this separation.
(Probably because the quality of the compiler would go down the tubes
right quick.)  Although...  hmmm..  I guess type information is used for
 some optimization (specializing = for ints and such).

Also you lose the compositionality as before - you can't break this
function into two parts because the second line "needs" the first line
to work.

> Summary:  I can see why it is useful to require that each field access
> be mapped to a globally-unique record type.  OCaml today does this by
> having the programmer explicitly name a globally-unique record type with
> every field access.  But couldn't this instead be done by type inference?
> 
> Thanks very much for your reply.
> ~Brighten


  reply	other threads:[~2008-08-13 12:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-10 10:04 Brighten Godfrey
2008-08-10 19:38 ` [Caml-list] " Jon Harrop
2008-08-12 21:03   ` Brighten Godfrey
2008-08-13  0:12     ` Edgar Friendly
2008-08-13  1:17       ` Brighten Godfrey
2008-08-13 12:48         ` Edgar Friendly [this message]
2008-08-14  6:38           ` Brighten Godfrey
2008-08-14 10:11             ` David Allsopp
2008-08-13  1:51     ` blue storm
2008-08-13  8:14     ` Richard Jones
2008-08-13  9:30       ` Brighten Godfrey

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=48A2D834.5020508@gmail.com \
    --to=thelema314@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.com \
    --cc=pbg@cs.berkeley.edu \
    /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