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

[Julien Fischer]

On Thu, 16 Feb 2006, Ralph Becket wrote:

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

For the benefit of all of involved in this discussion I draw your attention to
the following comment at the top of bintree.m:

	% Stability: medium (obsolete).
	%
	% This module exists primarily for historical reasons. It is unlikely
	% to be useful, and may not be supported in future releases.
	% You should use `map' instead.

Similarly for bintree_set.m.  AFAIK this is still the case and while it is
we won't be adding anything to these modules.

Julien.






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