FW: [mercury-users] Records

[Simon Taylor]

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

That wouldn't always work. In some cases multiple field updates must
be done as an atomic operation for type correctness.

:- type foo(T)
	---> foo(field1::T, field2::T, int, int).

:- func update_foo(foo(T)) = foo(int).

update_foo(In) = In ^ field1 := 1
		    ^ field2 := 2. 

The constructor resulting from setting the first field has type
`foo(int, T, int, int)'.

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