[m-dev.] trailed destructive update for arrays

Fergus Henderson fjh at cs.mu.oz.au
Wed Sep 10 17:40:56 AEST 1997


Peter Schachte, you wrote:
> On Mon, 8 Sep 1997, Fergus Henderson wrote:
> 
> > I've implemented the following module `tr_array.m' for trailed backtrackable
> > destructive update on arrays.  I'm planning to put this module in a 
> > new directory extras/trailed_update.
> > 
> > Comments?
> 
> Why put "mui" or "mdi" in the name of each predicate, rather than just
> making these different modes of the same predicate?  The "bt" in the module
> name already implies these predicates are 'mostly' destructive predicates.

That's to make it easier for people who want to omit the module qualifiers.

Without that, if you were to write

	:- import_module array, tr_array.
	foo(A0, A) :-					% this is line 002
		...
		set(A0, 42, 'x', A)
		...

then you would get a moderately obscure error message

	foo.m:002: In clause for predicate `foo:foo/2':
	foo.m:002:   error: ambiguous overloading causes type ambiguity.
	foo.m:002:   One or more of the predicates or functions called
	foo.m:002:   is declared in more than one module.
	foo.m:002:   Try adding explicit module qualifiers.

But maybe you're right, maybe it would be better to just require
people to use the module qualifiers.  On the other hand, the ideal
solution would be to go with your suggestion below:

> For that matter, why not just add these new modes to the existing
> destructive array module? 

This would indeed be desirable, but...
the current Mercury implementation does not support having both
`mdi' and `di' modes (or both `mui' and `ui' modes) for the same
predicate :-(

Another complication is that doing this would require some conditional
compilation in array.m, because these modes should only be provided for
grades with trailing.

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



More information about the developers mailing list