[mercury-users] Non-backtrackable references and di modes.

[Ralph Becket]

How far away are nested unique modes?  I ask because I'm currently crafting
code that needs to play around with two or more arrays, and each array
means threading a separate di/uo pair of arguments through my code.  The
upshot is that the code soon ends up being nigh on unreadable.  I think
readability *is* an issue as far as software engineering is concerned and
I'd really like to be able to wrap these things up in some larger structure.

Which brings me to wonder how nested unique modes will work in practice.

Say I have a hash table implemented using open addressing with double
hashing (that is, each entry has a unique id which is used to detect
hashing collisions and when a collision is detected a secondary hashing
scheme is used to place the new entry).  It's going to look something like
this:

:- type hash_id == array(id).
:- type hash_entry == array(entry).
:- type hash_table
	  ---> ht(hash_id, hash_entry, int /* Number of occupants. */).

Now, hash_ids and hash_entrys are going to be unique objects.  Therefore,
it seems, a hash_table must also be a unique object.  Now, if I have some
hash_table in X and do

	  X = ht(HashId, _, _)

to get at the hash_id field, surely I've destroyed the uniqueness of that
field?  Either that or I've destroyed X itself.  Both of these situations
are a bit of a disaster, so I assume I've got this wrong?  Or am I forced
to write code like

	  X = ht(HashId, HashEntry, N),
	  <do some processing>
        X' = ht(HashId', HashEntry', N')

every time I access *any* unique member.

I presume if I project out non-unique members such as N here then there is
no problem?

Cheers,

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