pattern matching and records vs tuples

pattern matching and records vs tuples

[Yoann Padioleau]

Hi, 

I've found that while records provide advantages over tuples, 
they also have disadvantages when it comes to evolution issues. 
If I decide to evolve code using a tuple type, for instance adding
new information and so extend a 4-uple in a 5-uple, then the compiler
will tell me all the places that I need to update, which is good.
If I use records instead, and have 4 fields, and I want to add again
some new information in a new field, then the way the compiler works
right now will not help me at all. E.g with this code 

  type record = { 
    field1: int;
    field2: int;
  }
  let foo = function 
   { field1 = v1; field2 = v2 } -> ...


If I extend record with a new field   field3, then ocaml will
not warn me and tell me to modify also the 'foo' function :(


So, would it be possible to extend the ocaml compiler with a simple
feature that let the programmer tell the compiler when he use 
an "exhaustive" pattern with record, e.g.

 let foo = function
 { field1 = v1; field2 = v2; NOTHING_ELSE} -> 

(the inverse of a '...')

Re: [Caml-list] pattern matching and records vs tuples

[Christophe TROESTLER]

On Tue, 14 Apr 2009 09:12:19 -0500, Yoann Padioleau wrote:
> 
> I've found that while records provide advantages over tuples, 
> they also have disadvantages when it comes to evolution issues. 
> If I decide to evolve code using a tuple type, for instance adding
> new information and so extend a 4-uple in a 5-uple, then the compiler
> will tell me all the places that I need to update, which is good.
> If I use records instead, and have 4 fields, and I want to add again
> some new information in a new field, then the way the compiler works
> right now will not help me at all. 

See http://ocaml.janestreet.com/?q=node/31

Cheers,
ChriS

Re: [Caml-list] pattern matching and records vs tuples

[Goswin von Brederlow]

Yoann Padioleau <padator@wanadoo.fr> writes:

> Hi, 
>
> I've found that while records provide advantages over tuples, 
> they also have disadvantages when it comes to evolution issues. 
> If I decide to evolve code using a tuple type, for instance adding
> new information and so extend a 4-uple in a 5-uple, then the compiler
> will tell me all the places that I need to update, which is good.
> If I use records instead, and have 4 fields, and I want to add again
> some new information in a new field, then the way the compiler works
> right now will not help me at all. E.g with this code 
>
>   type record = { 
>     field1: int;
>     field2: int;
>   }
>   let foo = function 
>    { field1 = v1; field2 = v2 } -> ...
>
>
> If I extend record with a new field   field3, then ocaml will
> not warn me and tell me to modify also the 'foo' function :(

On the other hand that is a verry good thing.

let set_field1 r x = { r with field1 = x }
let set_field2 r x = { r with field2 = x }

Try doing that with tuples and then add a 3rd, 4th, 5th field.

I have to say I didn't even know you could match a record partially
or have ever wanted to match a record at all. I use record only when I
have a collection of otherwise independent values. As such any
matching will be done on a single component of the record but never
pairs of them. At least I can't remember having done so before.

MfG
        Goswin

Re: [Caml-list] pattern matching and records vs tuples

[Yoann Padioleau]

Goswin von Brederlow <goswin-v-b@web.de> writes:

> Yoann Padioleau <padator@wanadoo.fr> writes:
>
>> Hi, 
>>
>> I've found that while records provide advantages over tuples, 
>> they also have disadvantages when it comes to evolution issues. 
>> If I decide to evolve code using a tuple type, for instance adding
>> new information and so extend a 4-uple in a 5-uple, then the compiler
>> will tell me all the places that I need to update, which is good.
>> If I use records instead, and have 4 fields, and I want to add again
>> some new information in a new field, then the way the compiler works
>> right now will not help me at all. E.g with this code 
>>
>>   type record = { 
>>     field1: int;
>>     field2: int;
>>   }
>>   let foo = function 
>>    { field1 = v1; field2 = v2 } -> ...
>>
>>
>> If I extend record with a new field   field3, then ocaml will
>> not warn me and tell me to modify also the 'foo' function :(
>
> On the other hand that is a verry good thing.
>

I didn't say records have only disadvantages.


> let set_field1 r x = { r with field1 = x }
> let set_field2 r x = { r with field2 = x }
>
> Try doing that with tuples and then add a 3rd, 4th, 5th field.
>
> I have to say I didn't even know you could match a record partially
> or have ever wanted to match a record at all. I use record only when I
> have a collection of otherwise independent values. As such any
> matching will be done on a single component of the record but never
> pairs of them. At least I can't remember having done so before.

Ok ... 

Sometimes people want the partial match behavior, but sometimes people
prefer another behavior, so I just propose a kind of annotation
in the pattern that describes what behavior the programmer wants.

>
> MfG
>         Goswin

Re: [Caml-list] pattern matching and records vs tuples

[Christophe Raffalli]

Dear list member,

A solution
 when you change a record (or the meaning of an integer) and want to 
make sure that you are warned by the compiler at
every place where this data is used is to encapsulate your type in a box 
replacing for instance

let x = 0 : int (number of eggs)

with

let box d = `A(d) and unbox (`A d) = d
let x = box 0 (*nomber of dozen of eggs*)

Once you have updated all your code, you can remove the "box" and "unbox".

It would be nice if all this could be automated ...

Cheers,
Christophe

Re: [Caml-list] pattern matching and records vs tuples

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Tue, Apr 14, 2009 at 10:12 AM, Yoann Padioleau <padator@wanadoo.fr>wrote:

>
> So, would it be possible to extend the ocaml compiler with a simple
> feature that let the programmer tell the compiler when he use
> an "exhaustive" pattern with record, e.g.
>
>  let foo = function
>  { field1 = v1; field2 = v2; NOTHING_ELSE} ->
>

I think this is a great idea (and something I've blogged about before, as
Christophe Troestler points out).  The thing I've never come up with a good
proposal for is what would be a pleasant syntax to indicate the
exhaustiveness of the pattern match.  I could imagine something terse like
this:

   let {! foo = foo; bar = bar; } = x

where the ! indicates that the pattern match should be exhaustive.  Such
terse notation would sadly be somewhat obscure.

Another thought I've had for making record matches lighter is to do the same
kind of trick that's done with labeled arguments, i.e., have

   let { foo; bar } = x

bind the variable foo to the x.foo, and bind bar to x.bar.   Similarly, it
might be nice for:

    let foo = 3 and bar = 3. in { foo;bar }

to be equivalent to

   let foo = 3 and bar = 3. in { foo = foo; bar = bar }

y

[-- Attachment #2: Type: text/html, Size: 1554 bytes --]

Re: [Caml-list] pattern matching and records vs tuples

[Pal-Kristian Engstad]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

Honestly, I'd prefer to have to annotate non-exhaustive records:

    let { foo = foo; bar = bar } = x

should only match { foo; bar }, but

    let { foo = foo; bar =  bar; .. } = x,

can match records with more labels.

PKE.

Yaron Minsky wrote:
> On Tue, Apr 14, 2009 at 10:12 AM, Yoann Padioleau <padator@wanadoo.fr 
> <mailto:padator@wanadoo.fr>> wrote:
>
>
>     So, would it be possible to extend the ocaml compiler with a simple
>     feature that let the programmer tell the compiler when he use
>     an "exhaustive" pattern with record, e.g.
>
>      let foo = function
>      { field1 = v1; field2 = v2; NOTHING_ELSE} ->
>
>
> I think this is a great idea (and something I've blogged about before, 
> as Christophe Troestler points out).  The thing I've never come up 
> with a good proposal for is what would be a pleasant syntax to 
> indicate the exhaustiveness of the pattern match.  I could imagine 
> something terse like this:
>
>    let {! foo = foo; bar = bar; } = x
>
> where the ! indicates that the pattern match should be exhaustive.  
> Such terse notation would sadly be somewhat obscure.
>
> Another thought I've had for making record matches lighter is to do 
> the same kind of trick that's done with labeled arguments, i.e., have
>
>    let { foo; bar } = x
>
> bind the variable foo to the x.foo, and bind bar to x.bar.   
> Similarly, it might be nice for:
>
>     let foo = 3 and bar = 3. in { foo;bar }
>
> to be equivalent to
>
>    let foo = 3 and bar = 3. in { foo = foo; bar = bar }
>
> y
>


-- 
Pål-Kristian Engstad (engstad@naughtydog.com), 
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Emacs would be a far better OS if it was shipped with 
 a halfway-decent text editor." -- Slashdot, Dec 13. 2005.



[-- Attachment #2: Type: text/html, Size: 2783 bytes --]

Re: [Caml-list] pattern matching and records vs tuples

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Tue, Apr 14, 2009 at 9:46 PM, Pal-Kristian Engstad <
pal_engstad@naughtydog.com> wrote:

>  Honestly, I'd prefer to have to annotate non-exhaustive records:
>
>     let { foo = foo; bar = bar } = x
>
> should only match { foo; bar }, but
>
>     let { foo = foo; bar =  bar; .. } = x,
>
> can match records with more labels.
>

You're right, that seems way better.  The syntax is really much clearer, and
I like exhaustiveness as the default.  The only problem is that it is
inconsistent with the current way the compiler behaves.  But if you add the
exhaustiveness checking only as a flag, and that flag is turned off by the
"...", then you're totally set.  That's very consistent with other checks in
the compiler, such as checks for unused variables.

I think this is a great suggestion.  I'm curious what Xavier thinks...

y

[-- Attachment #2: Type: text/html, Size: 1256 bytes --]

Re: [Caml-list] pattern matching and records vs tuples

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

> let { foo; bar } = x
> bind the variable foo to the x.foo, and bind bar to x.bar
> I'd prefer to have to annotate non-exhaustive records:>    let { foo =
foo; bar = bar } = x
> should only match { foo; bar }, but
>    let { foo = foo; bar =  bar; .. } = x,
> can match records with more labels.

Both of the above are supported in SML, which I've always felt has better
support for record patterns.


On Tue, Apr 14, 2009 at 9:46 PM, Pal-Kristian Engstad <
pal_engstad@naughtydog.com> wrote:

>  Honestly, I'd prefer to have to annotate non-exhaustive records:
>
>     let { foo = foo; bar = bar } = x
>
> should only match { foo; bar }, but
>
>     let { foo = foo; bar =  bar; .. } = x,
>
> can match records with more labels.
>
> PKE.
>
>
> Yaron Minsky wrote:
>
> On Tue, Apr 14, 2009 at 10:12 AM, Yoann Padioleau <padator@wanadoo.fr>wrote:
>
>>
>> So, would it be possible to extend the ocaml compiler with a simple
>> feature that let the programmer tell the compiler when he use
>> an "exhaustive" pattern with record, e.g.
>>
>>  let foo = function
>>  { field1 = v1; field2 = v2; NOTHING_ELSE} ->
>>
>
> I think this is a great idea (and something I've blogged about before, as
> Christophe Troestler points out).  The thing I've never come up with a good
> proposal for is what would be a pleasant syntax to indicate the
> exhaustiveness of the pattern match.  I could imagine something terse like
> this:
>
>    let {! foo = foo; bar = bar; } = x
>
> where the ! indicates that the pattern match should be exhaustive.  Such
> terse notation would sadly be somewhat obscure.
>
> Another thought I've had for making record matches lighter is to do the
> same kind of trick that's done with labeled arguments, i.e., have
>
>    let { foo; bar } = x
>
> bind the variable foo to the x.foo, and bind bar to x.bar.   Similarly, it
> might be nice for:
>
>     let foo = 3 and bar = 3. in { foo;bar }
>
> to be equivalent to
>
>    let foo = 3 and bar = 3. in { foo = foo; bar = bar }
>
> y
>
>
>
> --
> Pål-Kristian Engstad (engstad@naughtydog.com),
> Lead Graphics & Engine Programmer,
> Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
> Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
>
> "Emacs would be a far better OS if it was shipped with
>  a halfway-decent text editor." -- Slashdot, Dec 13. 2005.
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 4437 bytes --]

Re: [Caml-list] pattern matching and records vs tuples

[blue storm]

On Wed, Apr 15, 2009 at 2:44 AM, Yaron Minsky <yminsky@gmail.com> wrote:
> Another thought I've had for making record matches lighter is to do the same
> kind of trick that's done with labeled arguments, i.e., have
>
>    let { foo; bar } = x
>
> bind the variable foo to the x.foo, and bind bar to x.bar.

That part is achieved by the pa_records [1] syntax extension.
To my knowledge, it has not been port to post-3.10 camlp4 yet, but if
you're interested, I could probably do it.

[1] http://oandrieu.nerim.net/ocaml/#pa_records

Re: [Caml-list] pattern matching and records vs tuples

[Martin Jambon]

blue storm wrote:
> On Wed, Apr 15, 2009 at 2:44 AM, Yaron Minsky <yminsky@gmail.com> wrote:
>> Another thought I've had for making record matches lighter is to do the same
>> kind of trick that's done with labeled arguments, i.e., have
>>
>>    let { foo; bar } = x
>>
>> bind the variable foo to the x.foo, and bind bar to x.bar.
> 
> That part is achieved by the pa_records [1] syntax extension.
> To my knowledge, it has not been port to post-3.10 camlp4 yet, but if
> you're interested, I could probably do it.
> 
> [1] http://oandrieu.nerim.net/ocaml/#pa_records

It's in the works for the next release of OCaml, according to Xavier Leroy's
talk at the OCaml meeting in Grenoble (Feb 2009).

(Note to organizers: slides and video would be cool!)



Martin

-- 
http://mjambon.com/

Re: [Caml-list] pattern matching and records vs tuples

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Wed, Apr 15, 2009 at 5:30 AM, Martin Jambon
<martin.jambon@ens-lyon.org>wrote:

> blue storm wrote:
> > On Wed, Apr 15, 2009 at 2:44 AM, Yaron Minsky <yminsky@gmail.com> wrote:
> > That part is achieved by the pa_records [1] syntax extension.
> > To my knowledge, it has not been port to post-3.10 camlp4 yet, but if
> > you're interested, I could probably do it.
> >
> > [1] http://oandrieu.nerim.net/ocaml/#pa_records
>
> It's in the works for the next release of OCaml, according to Xavier
> Leroy's
> talk at the OCaml meeting in Grenoble (Feb 2009).


What's in the works?  The lighter record syntax (let { foo; bar } = x) or
the exhaustiveness check on record matches?  I vaguely remember hearing
something about the former, but not the latter.

y

[-- Attachment #2: Type: text/html, Size: 1271 bytes --]

Re: [Caml-list] pattern matching and records vs tuples

[Martin Jambon]

Yaron Minsky wrote:
> 
> 
> On Wed, Apr 15, 2009 at 5:30 AM, Martin Jambon
> <martin.jambon@ens-lyon.org <mailto:martin.jambon@ens-lyon.org>> wrote:
> 
>     blue storm wrote:
>     > On Wed, Apr 15, 2009 at 2:44 AM, Yaron Minsky <yminsky@gmail.com
>     <mailto:yminsky@gmail.com>> wrote:
>     > That part is achieved by the pa_records [1] syntax extension.
>     > To my knowledge, it has not been port to post-3.10 camlp4 yet, but if
>     > you're interested, I could probably do it.
>     >
>     > [1] http://oandrieu.nerim.net/ocaml/#pa_records
> 
>     It's in the works for the next release of OCaml, according to Xavier
>     Leroy's
>     talk at the OCaml meeting in Grenoble (Feb 2009).
> 
> 
> What's in the works?  The lighter record syntax (let { foo; bar } = x)
> or the exhaustiveness check on record matches?  I vaguely remember
> hearing something about the former, but not the latter.

The syntax { foo; bar }.


-- 
http://mjambon.com/

Re: [Caml-list] pattern matching and records vs tuples

[Goswin von Brederlow]

Pal-Kristian Engstad <pal_engstad@naughtydog.com> writes:

> Honestly, I'd prefer to have to annotate non-exhaustive records:
>     let { foo = foo; bar = bar } = x
> should only match { foo; bar }, but
>     let { foo = foo; bar =  bar; .. } = x,
> can match records with more labels.
> PKE.
> Yaron Minsky wrote:

I would actually like to propose that to work on a type
level. Currently we have:

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

type base = { x : int; }
val get_x : base -> int = <fun>
type more = { x : int; y : int; }

# get_x { x=1; y=2; };;
Error: This expression has type more but is here used with type base
----------------------------------------------------------------------

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:

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

type base = { x : int; }
val get_x : base -> int = <fun>
type more = { x : int; y : int; }

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


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


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}

All other changes would only affect the grammar and type inference I think.



Now what would happen with your example?

# type record = { foo : int; bar : float; baz : string }
type record = { foo : int; bar : float; baz : string; }

# let f x = let { foo = foo; bar = bar; .. } = x in (foo, bar)

What type is that?

1) val f : { foo : int; bar : float; baz : string; .. } -> int * float = <fun>
2) val f : record -> int * float = <fun>
3) val f : { foo : int; bar : float; .. } -> int * float = <fun>
4) val f : { foo : 'a; bar : 'b; .. } -> 'a * 'b = <fun>

I would say it should result in 3. And the type should always be the
minimum prefix required to match all occuring fields:

# let f x = let { foo = foo; baz = baz; .. } = x in (foo, baz)
val f : { foo : int; bar : float; baz : string; .. } -> int * string = <fun>



As a further extention the following syntax would be usefull:

# type base = { x : int }
  type more = { base with y : int };;

type base = { x : int; }
type more = { x : int; y : int; }

With this syntax more would always be a supertype of base even if the
base type gets altered.


MfG
        Goswin

RE: [Caml-list] pattern matching and records vs tuples

[David Allsopp]

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

Re: [Caml-list] pattern matching and records vs tuples

[Jacques Garrigue]

From: "David Allsopp" <dra-news@metastack.com>

> 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.

You can do this with SML#

http://www.pllab.riec.tohoku.ac.jp/smlsharp/

 # fun f x = #name x;
 val f = fn : ['a, 'b#{name:'a}. 'b -> 'a]
 # f {name = "Joe", age = 21};
 val it = "Joe" : string

But the compiler is rather clever...

Jacques Garrigue

Re: [Caml-list] pattern matching and records vs tuples

[Goswin von Brederlow]

"David Allsopp" <dra-news@metastack.com> writes:

> 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.

Yes. They don't share a common prefix except the empty one.

>> 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

Why? If you declare the binding as { x : int } as 'a -> 'a then it
works just like now. If you declare it as { x : int; .. } as 'a -> 'a
then it has to cope with super types. That is totaly up to you (as
writer of the bindings) to decide and to ensure. Ocaml should probably
provide a copy_record or clone_record helper function to simplify { r
with x = 1 } type alterations in C.

> 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

MfG
        Goswin