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

[Fergus Henderson]

On 18-Jun-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 18-Jun-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Hmm... limited_deconstruct would only be used when pretty-printing,
> > wouldn't it?  I don't think that is likely to be performance-critical.
> 
> First, pretty-printing of large data structures may sometimes be useful,
> e.g. for debugging. Second, why constrain a potentially generally useful
> facility just because you can't think of another use right now? Maybe your
> current location is influencing your thinking :-)

We're not talking about constraining an existing facility,
we're talking about adding a new facility.

The new facility proposed looks ugly to me, because it violates the
principle of keeping the interface simple and providing just the
basic building blocks, together with powerful ways of combining them,
rather than trying to provide every individual combination of features.

The proposed justification for the new facility is efficiency.

What influences my thinking here is the desire to avoid the evils of
premature optimization.  Complicating the interface and implementation
with an extra procedure in order to speed up pretty-printing by 2% or
even 10% would not be a good trade-off, IMHO.  And so far I haven't seen
any convincing evidence that the speed up would be that great.

> > Also, you don't need to do the test for all types, it's enough to do it
> > just for arrays.
> 
> Testing the type just so you can avoid another test is not a good idea.
> Not all applications, even in prettyprinting, would test the type anyway,
> so the type test is not always free.
> 
> You are arguing for a more limited solution than I have implemented,

Both solutions are equally expressive.  I'm arguing for favouring
simplicity over unmeasured and probably unimportant performance gains.

In the long run, keepings things simple will often improve performance,
because it makes them easier to optimize.

> and for perpetuating the inefficiency currently in functor and deconstruct,
> which my change eliminates.
>
> My change also *improves* consistency wrt what
> fields are filled in in what circumstances.

I'm not arguing against the parts of your change which just reorganize the
implementation of the current interface -- at first glance it seems to
complicate the implementation, but I haven't really looked at the code
in any detail, so I don't yet have any firm opinion on that.

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