[m-dev.] problems with unique modes

[Fergus Henderson]

Andrew Bromage, you wrote:
> 
> G'day.
> 
> > 2.  We will need to be able to handle is code of the form
> > 
> > 	( uniq_array__insert(Array0, Key, Value, Array1) ->
> > 		Array = Array1
> > 	;
> > 		Array = Array0
> > 	)

Uh, sorry, I got that example wrong.  s/uniq_array/tree234/
and s/Array/Tree/g

> As a matter of interest, why can't we oblige people to write this?
> 
> 	( uniq_array__bounds_check(Array0, Key, Value) ->
> 		uniq_array__insert(Array0, Key, Value, Array)
> 	;
> 		Array = Array0
> 	)

In the case of tree234__insert, that would be

 	( tree234__search(Tree0, Key, Value) ->
 		tree234__insert(Tree0, Key, Value, Tree)
 	;
 		Tree = Tree0
 	)

The problem here is that you have to traverse the tree twice.
That is highly undesirable.

> Or perhaps:
> 
> 	uniq_array__try_insert(Array0, Key, Value, Array1),
> 	( Array1 = yes(Array)
> 	; Array1 = no(Array)
> 	)

Work-arounds like this would work, but they are a bit ugly.

Since the aim of all this destructive update stuff is efficiency,
the extra memory allocation for the yes/1 or no/1 constructor
is unfortunate; you can avoid it in this case by returning a bool
and an array, but that won't always be possible.

It is unfortunate that the interface for the destructive version needs
to be different to the interface that you would use for the
nondestructive version.

It is also unfortunate that it is not clear from the interface
for the destructive version that if `try_insert(Array0, ...)'
returns `no(Array)', then Array is an unmodified Array0.

I suppose we could live with all that, but it is a bit annoying.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.