From: John Max Skaller <skaller@ozemail.com.au>
To: Don Syme <dsyme@microsoft.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Record pattern matching
Date: Tue, 08 May 2001 04:37:43 +1000 [thread overview]
Message-ID: <3AF6EB77.E5473778@ozemail.com.au> (raw)
In-Reply-To: <0C682B70CE37BC4EADED9D375809768A48FDDC@red-msg-04.redmond.corp.microsoft.com>
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
next prev parent reply other threads:[~2001-05-13 19:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-07 15:33 Don Syme
2001-05-07 18:37 ` John Max Skaller [this message]
2001-05-10 18:43 Don Syme
2001-05-11 8:00 ` Andreas Rossberg
2001-05-11 9:04 ` John Max Skaller
2001-05-12 17:11 ` Brian Rogoff
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=3AF6EB77.E5473778@ozemail.com.au \
--to=skaller@ozemail.com.au \
--cc=caml-list@inria.fr \
--cc=dsyme@microsoft.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