[m-dev.] [revised] for review: bintree.m -- open type /representation/

[Ralph Becket]

doug.auclair at logicaltypes.com, Wednesday, 15 February 2006:
> Dear Ralph, thank you for your response.  You wrote:
> 
> >This is not a good idea!  The bintree structure has to observe the
> >ordering invariant, which is enforced by requiring users to use
> >the interface presented by bintree.
> 
> Ah! Okay, given that, the below change externalizes a one-way
> /representation/ of bintree, which, given the revised protocol (the
> one-way representation/2 predicate), does not allow the internal
> ordering to be disturbed:

Maybe a better solution would be to just introduce a deconstruction
predicate to bintree:

:- interface.

	% Fails on empty bintrees.
	%
:- pred deconstruct(bintree(K, V)::in, K::out, V::out,
	bintree(K, V)::out, bintree(K, V)::out) is semidet.

:- implemenation.

deconstruct(tree(K, V, L, R), K, V, L, R).

> >You haven't explained why you want to see the structure of the bintree.
> >If you make a good enough case, we'll happily extend the interface to
> >accommodate you without compromising the bintree invariants.
> 
> The above set of changes does not compromise the bintree invariants,
> so I hope this resolves the issue.  As for the "why", due to
> constraints on me from the client, I can neither discuss them nor
> their business process -- I would need to get into their business
> process to produce a  relevant example for the changes.  So, I must
> stand by my initial example and need: different kinds of traversal
> over the structure of the type.  Sorry.

Our problem is that, for maintenance reasons, we don't want to fill up
the bintree module interface with additions for one-off applications.
Sometimes it is better to just code up your own data type for these
things.  If there was a concrete reason we could understand (i.e., more
than that your client's confidential spec. requires it), it would lend
more weight to the argument for extending the interface.

-- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------