Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Record pattern matching
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] Record pattern matching
Don Syme wrote:
> 
> In OCaml record patterns may be inexact, i.e. you do not have to specify
> all the fields.
> 
> # type x = {a:int; b:int};;
> type x = { a : int; b : int; }
> 
> # function {a=a} -> a;;
> - : x -> int = <fun>
> 
> # function {b=b} -> b;;
> - : x -> int = <fun>
> #
> 
> I guess this is considered a feature, but I just wanted to report that
> in my current situation I actually find it unhelpful. 

	You'd rather be forced to code something like:

	function { a=a; b=_ } -> a;;

where all the fields have to be named, but some of them can be specified
as ignored?

> # type x = Foo of int * int;;
> type x = Foo of int * int
> 
> # function (Foo (x)) -> x
> Characters 10-17:
> The constructor Foo expects 2 argument(s),
> but is here applied to 1 argument(s)

	Actually .. I just got bitten by a 'counterexample' to this
assertion :-) Consider the following:

	type t = Ctor int * int
	match Ctor (x,_) -> fst x

Now, I change it:

	type t = Ctor int * (int * int)
	match Ctor (x,_) -> fst x

This code still compiles, it still type checks, and it still operates:
but it returns the wrong value entirely. This problem would
go away if I were forced to model the entire structure:

	match Ctor (x,(_,_))
 
but there is no easy way to say where the level of detail should stop.

There is a sense in which

	record.a

is just a shorthand for

	match record with { a=value } -> value

which means that you might argue that the notation 

	record.a

should be completed by naming every field too :-)

What you might do is change the field names in the record:
this will certainly give an error on every record access
(but that might be more than you want :-)

however, that suggests a pragmatic technique -- although
it would have to be 'retrofitted': to each record,
add a dummy field:

	type t = { bank_account_v_1: unit; a : int; .... }

and add _that_ to all your matches:

	function { bank_account_v_1=dummy; a = a } -> a

When you extend or change the record, modify that field:

	type t = { bank_account_v_2 : unit; ... }

and the match above will now fail, while field access
with '.' will continue to work.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr