FW: [mercury-users] Records

[Richard A. O'Keefe]

	> To avoid the need for explicit type qualifiers in situations like
	> that, I think it would be a better idea to use `get_<fieldname>'
	> and `set_<fieldname>' (e.g. `get_f' and `set_f'),
	> or perhaps just `<fieldname>' and `set_<fieldname>'.
	
I can't think of anything sillier than using 'get' and 'set'.
1)  They only differ in a single letter.
2)  The word "get" conveys no information whatsoever.
Just because Java does it doesn't mean it's a good idea (usually
the opposite, in my view).

Note that the update version of a field name does not have to be
a plain identifier.  It could be something that requires quotation
marks.  Just as an example, what's wrong with

	f of X	<=> f(X)
	f of X := V  =>  'f:='(X, V)

More to the point, a record update notation should _smoothly_ handle
N fields, not just 1.  Clean's syntax,
	{ record & field1 = value1, ..., fieldn = valuen }
does this, and neatly mirrors the syntax for array update:
	{ array & [index1] = value1, ..., [indexn] = valuen }

The idea that record updates must work one field at a time is an
artefact of imperative thinking, burned into our minds by Pascal and C.
It's time for recovery.  Why should we have to decide whether to do
	R1 = f of R0 := V1,
	R2 = g of R1 := V2
(revealingly, while typing that I nearly made the mistake of typing
R0 instead of R1) or
	R1 = g of R0 := V2,
	R2 = f of R1 := V1
when we could do
	R2 = R0 with [f := V1, g := V2]
or something of the sort?

It is *essential* to do this if records can have integrity constraints,
becuase there will often be *no* one-field-at-a-time update which
preserves integrity.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------