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

[Mark Brown]

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

I don't completely agree here.  Although accepting option 3 does not
commit us to this option forever, it is still likely to de-motivate us
from making future beneficial changes for the reasons that Fergus
mentioned: the amount of code that must be understood and modified in
order to make a change.  It is likely that somebody making a change in
the future will not be aware of (or will have forgotten) option 2, and
will therefore have a more difficult task facing them.

Having said that, I don't think the argument against option 3 is strong
enough to warrant changing to option 2, simple as that change would be.
I have reviewed most of the code, and I don't think it is as difficult
to understand as it looks at first.  IMHO, neither option is ideal but
either would be acceptable, so I'll continue reviewing the current diff
rather than ask for a different approach.

Cheers,
Mark.

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