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

[Fergus Henderson]

On 19-Jun-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 19-Jun-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > As I said earlier, certainly we should fix the problem that was
> > causing things to be infeasible, the only question is how.
> > The efficiency difference between the two different ways of
> > fixing it is small.
> 
> Which two ways are you referring to? I can see more than two.
> 
> 1. Don't add limited_deconstruct, and make everyone program their own arity
>    test if required.
> 
> 2. Add limited_reconstruct with the simple "arity test then deconstruct"
>    implementation.
> 
> 3. Add limited_reconstruct with the implementation in my diff.

I was referring to 1 and 3.

> You said you favoured option 1. This does have a big efficiency downside,
> because the chance that someone will omit the arity test when it is required
> is significantly higher with option 1 than with the other two options.
> Getting people to use the safe version is a lot easier if they don't have to
> pay an efficiency penalty for doing so, regardless of the size of the penalty.
> 
> My arguments are that (a) there are no valid grounds on which option 1 is
> superior to option 2, while there are grounds (e.g. avoidance of code
> duplication) on which option 2 is superior to option 1, and (b) option 3,
> being more efficient (and therefore more likely to be used) at acceptable cost
> in simplicity, is preferable for now to option 2, but there is nothing to
> prevent us from switching to option 2 in the future if it becomes warranted.
> 
> The only counter-argument you have made to argument (a) was that options
> 2 & 3 "complicate" the interface, which I believe I have refuted; the
> complexity exists, whether it is made explicit or not. The only
> counter-argument you have made that is relevant to argument (b) was about
> option 3 being possibly hard to modify. I agree with that, but it doesn't
> refute argument (b), since argument (b) is not committing us to option 3
> forever.

These are good arguments.

However, with regard to (a), I don't agree; there is a difference.
If you leave the complexity implicit, then the solution is compositional,
whereas if you make it explicit using `limited_deconstruct', then the
solution is no longer compositional, and so doesn't scale as well.

What I mean here is that whether you expose the need (in some cases)
to check the arity via an explicit `limited_deconstruct' procedure or
just by documenting the issue does make a difference to the interface
complexity.  In particular, documenting the "user-does-the-arity-check"
approach is better if you have lots of different versions of deconstruct,
because it increases the size/complexity of the interface to deconstruct
and its variants by a constant amount, rather than doubling the number
of different variants.

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