FW: [mercury-users] Records

[Simon Taylor]

> On Mon, Nov 08, 1999 at 10:52:24AM +1100, Simon Taylor wrote:
> > > 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>'.
> > 
> > The only complaint I have with using magic function names for which
> > definitions can be automatically generated by the compiler is that
> > typos can result in difficult to spot bugs where the programmer's
> > version is not called.
> 
> Can you give an example?  As far as I can see, all that'll happen if
> you spell the field name differently in the definition and use is that
> you'll get a complaint about an unknown function.  If the code that
> does the X ^ F ==> F(X) translation does some checking, it could even
> give a more helpful message.

:- type foo
	---> foo(
		field1::int,
		field2::int
	).
:- func 'set feild1'(foo, int) = foo.

I don't see how the compiler can check for that kind of error if it
can't distinguish user-defined access functions from other functions.
 
> > and reporting an error for get and set functions for which there is no
> > matching field.
> 
> My main point was that you shouldn't do that.  It's very useful to be
> able to use the same syntax to access and modify both real and "fake"
> fields.  This allows a type with field accessors/setters to still be
> an ADT.
>
> > We'd also need a `:- derived_field <fieldname>' declaration.
> 
> What's that for?

To declare the "fake" fields, so that you don't get undefined field
errors for their access functions.

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