RE: [Caml-list] Record pattern matching

RE: [Caml-list] Record pattern matching

[Don Syme]

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

I guess the point is that I don't use record pattern matching much, and
where I do I don't want partial matches.  Or at least I have a cases
where enforcing full matching would catch more bugs.  For example, if
I'm writing marshalling code for the record by hand I want the type
system to tell me if I have forgotten to marshal a field.

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

You could argue that, but I wouldn't....

Don
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Record pattern matching

[Andreas Rossberg]

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

No, but as Don suggested having alternative syntax would be preferable.
SML for example distinguishes the patterns

	{a = p}

and

	{a = p, ...}

> I guess the point is that I don't use record pattern matching much, and
> where I do I don't want partial matches.  Or at least I have a cases
> where enforcing full matching would catch more bugs.

This has been my experience as well when modifying record types.

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

In SML the record selection function #a in fact is sugar for

	fn {a=x, ...} => x

Best regards,

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids.
 If Pac Man affected us as kids, we would all be running around in
 darkened rooms, munching pills, and listening to repetitive music."
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Record pattern matching

[John Max Skaller]

Andreas Rossberg wrote:

> SML for example distinguishes the patterns
> 
>         {a = p}
> 
> and
> 
>         {a = p, ...}

	Thats nice. Might be a compatibility problem for Ocaml though.
 

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

Re: [Caml-list] Record pattern matching

[Brian Rogoff]

On Fri, 11 May 2001, Andreas Rossberg wrote:
> > >       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?
> 
> No, but as Don suggested having alternative syntax would be preferable.
> SML for example distinguishes the patterns
> 
> 	{a = p}
> 
> and
> 
> 	{a = p, ...}

This seems like a good solution to this problem.

> > I guess the point is that I don't use record pattern matching much, and
> > where I do I don't want partial matches.  Or at least I have a cases
> > where enforcing full matching would catch more bugs.
> 
> This has been my experience as well when modifying record types.

OK, just to provide another data point, I use the partial match feature
quite a bit. The "..." notation is light enough that the feature is still 
convenient, which would not be the case if each named field would have to
be explicitly named. I've also been reading a lot of SML code that I
haven't written lately and I find that notation quite readable and
concise.

As an aside, the situation with records is still not very satisfying. In
some cases I use objects when I really just want flexible records, where I 
can define functions over all records types with given fields. It seems
that would be more "symmetric" too, with respect to polymorphic variants.
I gather something like that has been tried already and found wanting?

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Record pattern matching

[Don Syme]

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.  I'm in the
process of adding fields to a large number of existing records in a
large existing code base, and would like the type checker to notify me
every time a pattern match is used against one of these record types -
essentially every place where I do such a pattern match I will have some
extra work to do and I'd rather the type checker guided me to these
locations.

If I had encoded the type as a datatype constructor, then the rules are
of course different:

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

It seems you're faced with an unfortunate either-or: you lose some
strictness in your type checking (i.e. the type checker ends up catching
less bugs), or you lose the syntactic convenience of records.  

I don't really have a suggestion as to what to do about this, though I
guess I would prefer if pattern matching against records was strict, or
if an alternative syntax could be used for stricter record patterns.  As
an aside, I would also prefer it if you did not have to use the "{a=a;
b=b}" syntax but could write "{a; b}".

Thanks,
Don


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Record pattern matching

[John Max Skaller]

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