Version française
Home     About     Download     Resources     Contact us    
Browse thread
pattern matching and records vs tuples
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] pattern matching and records vs tuples
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