FW: [mercury-users] Records

[Peter Schachte]

On Mon, Nov 08, 1999 at 02:40:20PM +1300, Richard A. O'Keefe wrote:
> I can't think of anything sillier than using 'get' and 'set'.
> 1)  They only differ in a single letter.

Not to mention that `g' and `s' don't even look all that dissimilar.
I thought I was the only person who was bothered by this!

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

Infix `of' isn't bad, but I think there's something nice about having
the function name come second.  You can think of it a lot like unix
piping.  It allows you to understand the computation from left to
right, rather than from inside out with standard functional notation.

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

I kind of like 'f:='.  It makes the relationship between `:=', f, and
the setter a little bit more natural than 'set f'.

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

I'm not crazy about this use of `&', but the idea of multiple updates
in a single goal is good.

> 	R1 = f of R0 := V1,
> 	R2 = g of R1 := V2

You can chain the :='s:

	R2 = R0 ^f := V1
	        ^g := V2

(though you have to get the precedences and associativities of ^ and
:= right.)  It's a little strange, but with careful layout, I think
it could become a readable idiom.

> 	R2 = R0 with [f := V1, g := V2]

That's nice, but not all that dissimilar to the chained assignments
example above.

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

I hadn't thought to tackle *that* question.  It'd be nice, but I don't
see a way to do it right now.  Too many combinations.  Do you have a
proposal?

Maybe one way to handle it would be to allow users to attach integrity
constraints to types, and then (perhaps controlled by debugging
options) verify that the constraint is satisfied whenever a new term
of that type is created.  But it skip checking the integrity of terms
used as nothing other than an input to a function whose name ends with
`:=' (ie, don't check integrity of intermediate terms).  It sounds
just a little bit ad hoc :-), but I think it would work.

-- 
Peter Schachte                     A billion here, a couple of billion there
mailto:schachte at cs.mu.OZ.AU        -- first thing you know it adds up to be
http://www.cs.mu.oz.au/~schachte/  real money.
PGP: finger schachte at 128.250.37.3      -- Senator Everett McKinley Dirksen 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------