[m-dev.] for review: --dead-code

[Fergus Henderson]

On 22-Jul-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 21-Jul-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > The main
> > difference from standard lazy evaluation are that the decision
> > as to whether something will be needed is made at compile time,
> > and is thus necessarily more conservative.
> 
> .. in my view, this conservatism means that you don't get any of the
> guarantees that lazyness gives you. OTOH, you don't have to pay any
> of the overheads of lazyness either. In my view, these two things are
> what people think of when you mention lazyness. Overall, I think including
> lazyness in the name would cause unnecessary confusion.

Fair enough.

> Well, to me "redundant" covers the second case as well as the first.
> However, I am open to further suggestions.

Well, I had a look through a thesaurus or two, but I didn't find
anything that sounded better.  So unless anyone else can suggest
anything, it's up to you.

> > > > ... since the implementation uses `inst_matches_binding',
> > > > which ignores uniqueness, and which fails for `any' insts.
> > > 
> > > What is the correct test then?
> > 
> > Well, that depends on what it is you're trying to test.
> > I don't yet understand what this code is trying to achieve.
> 
> I am trying to find out which variables have been further instantiated.
> This means that I am trying to ignore differences between their initial
> and final inst wrt inst names, wrt uniqueness, and wrt knowledge of what
> functors parts of the variable are bound to.

OK, in that case the names and documentation that you had for those
predicates (proc_info_changed_inst_headvars and
proc_info_unchanged_inst_headvars) was misleading.

> Surely a predicate for checking this must already exist.

Actually because of dynamic moding there is no way to find out at
compile time which variables have been further instantiated, since
that can vary at run time.  You can only find out either (a) which
variables will _definitely_ have been further instantiated or (b)
which variables _might_ have been further instantiated.  For (b),
`inst_matches_binding' is the right procedure to use.  For (a), I
don't think there is any existing procedure which does exactly the
right thing.  Probably you want (b).

So I think the code is fine, it's just that the documentation
was misleading.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------