FW: [mercury-users] Records

Ralph Becket rbeck at microsoft.com
Wed Nov 3 00:09:37 AEDT 1999


> Hmm perhaps I misinterpreted the post, but it seemed to be a mere
> syntactical addition to allow the deconstruction of compound 
> terms using
> indexing by name rather than position. For example:

No, I think you're correct: the proposed record scheme is just syntactic
sugar.

> That kind of syntactical magic seems reasonable, and allows you to
> reshuffle the order of items in large structures without breaking too much
> code. Making some items in triple "read-only" doesn't seem to  make much
> sense, though it depends what use you had in mind. Isn't every logical
> variable effectively read only? Using the new "assignment" 
> syntax is still not changing anything

I'm not confused about the declarative aspects!  

What I had in mind was something where I could declare an abstract type,
but allow users of that type partial access to it via the record syntax.
e.g. rather than writing

:- interface.
:- type foo.
:- func get_field1(foo) = int.
:- func set_field1(foo, int) = foo.
:- func get_field2(foo) = string.

:- implementation.
:- type foo ---> foo(int, string, bool /* my extra field */).
...

I was asking whether the record scheme would cover this sort of thing
for me.  In this case the user can copy foos and notionally access
field1 (rw) and field2 (ro), but not get at the private state (the bool).
This is similar to the private, public, final stuff in Java (which, btw,
lacks a proper read-only declaration).

> zero_second_field_in_triple(X, X ^ second := 0).
> 
> Actually I'm not sure if that's valid code under the new 
> record regime,
> but it's something along those lines.

I'd rather hope that would be valid code...

I'm keen on having records with named fields in the language because
I've worked on large projects (in Prolog) which had terrible problems
whenever somebody added an extra field to a commonly used structure
which was accessed by pattern matching rather than some more controlled
interface.  All sorts of things went wrong (and, it being Prolog, you
didn't get to find out until run-time).

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