[m-rev.] for review: arrays and the debugger

[Fergus Henderson]

On 18-Jun-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Suppose we decide to optimize deconstruct by providing an alternative
> version that returns an array rather than a list.  Then we'll have four
> different versions rather than two.  Next, remember that we have to
> implement these in several different languages, for the different
> back-ends (C, Java, and C# or Managed C++).  Pretty soon all these
> different versions start to add up.

I forgot to mention that we also need alternative versions of deconstruct
that work on types with user-defined equality (and which hence must have
determinism cc_multi/cc_nondet).

Hmm, that makes 8 different versions, with as many as 24 different
implementations.  And that's just for deconstruct.
This is starting to get too complex already, IMHO.

Perhaps we can get away with combining some of these different versions.
Let's see...  the versions that return an array definitely need to be
separate functions/predicates, since they return a different type.
The versions for non-canonical types definitely need to be separate
procedures, since they have different determinisms.  (In theory, they
could potentially be just different modes of a single predicate rather
than different predicates, using an extra argument to select which
mode you want, but that would add complication without really gaining
anything.)

So, any ideas as to how we could or should manage this complexity?

If it comes down to choosing between

	(a) versions that support non-canonical types;
	(b) versions that return arrays rather than lists;
	(c) limited arity versions; and
	(d) less than 8 different versions with less than 24
	    different implementations

then I'd probably rank these in the order (a),(b),(d),(c).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------