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

[Zoltan Somogyi]

On 19-Jun-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 	(d) less than 8 different versions with less than 24
> 	    different implementations

What 24 implementations you are you thinking of? At the moment, there is one
implementation of the complicated stuff, which has several knobs, one for each
variant. The variants are compositional. Adding a knob for types with
user-defined equality would be simple. Adding a knob for returning stuff in
arrays would not even require a knob, as it could be handled simply by
foreign_procs that avoid the current post-processing step for turning pairs of
arrays into lists of univs. (I am about to make that step into a separate
function in response to Mark's review comments.)

It is true that the number of predicates in the user interface grows
geometrically with the number of orthogonal decision such whether you throw
exceptions for user-defined types and whether you return the output in arrays.
However, limited_deconstruct is a not such a decision. It adds a fourth basic
predicate (besides functor, arg, and deconstruct) that each combination
of decisions must implement. Its provision does not double the number of
predicates in the user interface; it increases it only by one third. On this
basis, it is less of a problem than providing argument, det_argument and
det_arg as well as arg, since these collectively *do* double the number of
predicates in the user interface.

I don't think the number of predicates in the interface is the best measure of
complexity of that interface, anymore than the number of instructions in an
instruction set is a measure of whether an instruction set is a RISC. What
matters is regularity.

With your proposal, we would have the following predicates:

	functor
	arg
	argument
	det_arg
	det_argument
	deconstruct

	ude_functor
	ude_arg
	ude_argument
	ude_det_arg
	ude_det_argument
	ude_deconstruct

	array_deconstruct

	array_ude_deconstruct

Only deconstruct needs array-specific versions, since the others return fixed
numbers of items. The naming scheme of course should be improved.

Note that programmers do not need to remember separately what each predicate
does. They can simply remember what the basic predicates do, and rules such as
"ude_X is the same as X, except it works on types with user-defined equality
and its determinism therefore includes a committed-choice context".

With my proposal, we have four more, one in each group:

	limited_deconstruct
	ude_limited_deconstruct
	array_limited_deconstruct
	array_ude_limited_deconstruct

That's 18 predicates vs 14; not a very sharp difference. (I don't know how you
counted 24.) There is no difference in regularity. If you accept that
programmers must be aware of the performance problems of deconstructing large
arrays, and you seem to, there is no difference in overall complexity either;
the only question is which predicate's comments contain the warning,
and whether programmers must write their own test.

I see those four extra predicates a cheap price to pay for encouraging
programmers to write code that doesn't have "fall-off-the-cliff" performance
problems in rarely tested situations.

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