FW: [mercury-users] Records

Ralph Becket rbeck at microsoft.com
Wed Nov 3 22:35:30 AEDT 1999


> 	:- module foo3.
> 	:- interface.
> 	:- type t3
> 		---> private t3(
> 			const field1 :: int,
> 			private field2 :: int
> 		).
> 	:- implementation.
> ...

Agree so far.
> 
> The `private' annotation on `field2' means that the field 
> extraction and
> update expressions cannot be used outside module `foo3'.

If field2 cannot be used outside the defining module, then I don't think
it should appear in the interface section at all.  If nothing else, the
above could lead to confusion on the part of someone reading the
interface.

> One other idea I had was that one of the reasons for making a 
> field private
> is that there is an invariant on the field that must be checked on
> each update. It would be a shame to have to use different syntax for
> updating such fields. One way to fix that would be allow the user
> to override the field update function.
> 
> 	:- module foo4.
> 	:- interface.
> 	:- type t4
> 		---> t4(
> 					% field1 must be positive.
> 			field1 :: int where set is set_field1,
> 			field2 :: int
> 		).
> 
> 	:- func set_field1(t4, int) = t4.
> 
> 	:- implementation.
> 
> 	set_field1(Term0, Value) = 'builtin_set field1'(Term0, Value) :-
> 		( Value < 0 ->
> 			error("negative value for field1")
> 		;
> 			true
> 		).
> 
> 'builtin_set field1' is the usual expansion into unifications for
> a field update expression (Term0 = t4(_, X2), Term = t4(Value, X2)). 
> 
> 'builtin_set field1' cannot be overridden by the programmer, and
> cannot be called by modules importing module `foo4'.

Yes, Visual Basic has something like this with its notion of `properties'
on objects.  I like the idea of having checked assignments and recomputed
(rather than stored) fields.

However, this is all starting to niggle my sense of aesthetics.  Perhaps
the best thing to do is to just keep it simple and write out the special
cases by hand.  Hmm...

> That kind of programmer will find ways to stuff things up no matter
> how nice the language.

On that project it wasn't just *a* programmer, it was a whole culture.

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



More information about the users mailing list