caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David Allsopp" <dra-news@metastack.com>
To: "'Goswin von Brederlow'" <goswin-v-b@web.de>,
	"'Pal-Kristian Engstad'" <pal_engstad@naughtydog.com>
Cc: <yminsky@gmail.com>, <caml-list@inria.fr>
Subject: RE: [Caml-list] pattern matching and records vs tuples
Date: Thu, 16 Apr 2009 17:59:13 +0100	[thread overview]
Message-ID: <000b01c9beb4$ac3d50a0$04b7f1e0$@com> (raw)
In-Reply-To: <87tz4opori.fsf@frosties.localdomain>

Goswin von Brederlow wrote: 
> I would actually like to propose that to work on a type
> level. Currently we have:
> 
> I propose that records can be subtyped if their prefix matches and
> ".." would be used to denote the subtype of any record with this
> prefix:
> 
<snip>
> One could also declare get_x to accept supertypes:
> 
> # let get_x (r : { x : int; .. }) = r.x;
> val get_x : { x : int; .. } -> int = <fun>
> 
> # get_x { x=1; y=2; };;
> - : int = 1

Bear in mind that for this work the label must be at the same ordinal
position within both record types for this to work (which I think could
potentially be irritating). For example, given:

# type base = { x : int }
  let get_x r = r.x
  type more = { y : int; x : int };;

# get_x ({ y=2; x=1; } :> base);;

You would have to get a type coercion error message.

> I think there is only one thing that would need to be changed for the
> compiled code with record subtypes like the above. Copying and
> modifying a record would need allocate a block matching the size of
> the input record and not the size of the subtype. Think about this
> code:
> 
> # let change_x (r : { x : int; .. }) x = { r with x = x }
> val change_x : { x : int; .. } as 'a -> int -> 'a = <fun>
> # change_x { x=1; y=2; } 2;;
> - : more = {x = 2; y = 2}

I imagine that it's a reasonably rare thing to do, but any C bindings which
manipulate record types in this way would break (and probably segfault the
runtime) if this behaviour were required. The other worry in the back of my
mind is that despite having considerably more flexible records in SML (you
don't have to declare the types in advance and label sharing is possible), a
function in SML still has the restriction of only being over a fixed record
type ... and when SML has odd restrictions, they're usually to do with the
more "obvious" type system feature being undecideable. For example, you
can't say in SML:

fun get_x r = #x r;

as the equivalent of the OCaml get_x you propose.


David


  reply	other threads:[~2009-04-16 16:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 14:12 Yoann Padioleau
2009-04-14 16:00 ` [Caml-list] " Christophe TROESTLER
2009-04-14 16:40 ` Goswin von Brederlow
2009-04-14 16:58   ` Yoann Padioleau
2009-04-14 20:01     ` Christophe Raffalli
2009-04-15  0:44 ` Yaron Minsky
2009-04-15  1:46   ` Pal-Kristian Engstad
2009-04-15  2:37     ` Yaron Minsky
2009-04-15  2:40     ` Ashish Agarwal
2009-04-16 16:05     ` Goswin von Brederlow
2009-04-16 16:59       ` David Allsopp [this message]
2009-04-17  0:26         ` Jacques Garrigue
2009-04-17 21:12         ` Goswin von Brederlow
2009-04-15  7:41   ` blue storm
2009-04-15  9:30     ` Martin Jambon
2009-04-15 11:01       ` Yaron Minsky
2009-04-15 12:04         ` Martin Jambon

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='000b01c9beb4$ac3d50a0$04b7f1e0$@com' \
    --to=dra-news@metastack.com \
    --cc=caml-list@inria.fr \
    --cc=goswin-v-b@web.de \
    --cc=pal_engstad@naughtydog.com \
    --cc=yminsky@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).