[m-dev.] diff: add eval_method_uses_table

Zoltan Somogyi zs at cs.mu.OZ.AU
Wed Jan 26 17:21:37 AEDT 2000


>> Nope, this centralized test is not what I meant in my previous mail. What
>> I meant is that *each individual piece of code that examines the eval method*
>> must contain its own switch on eval method.
> 
> I don't think that is a good idea; if several places are making the same
> semantic test, then that code should be abstracted out into a separate
> predicate, not duplicated.

My point is precisely that they *arent'* making the same semantic test.

The ones that are, sure they should share code, but there are several that
don't. It just happens that for the current set of eval methods, all the
semantic tests happen to have same answer.

> OK, my code is assuming that every procedure which uses tabling has its
> own tabling pointer.  If you need to add something which breaks that
> assumption, then I suggest you define a similar boolean function
> called say `eval_method_needs_tabling_pointer', and then go through all
> the calls to `eval_method_uses_table', changing some of them to
> `eval_method_needs_tabling_pointer'.

Sure, that is exactly what I intend to do. I just think that having just one
predicate, `eval_method_uses_table', is not the right abstraction even now.
The code in inlining.m should call `eval_method_cannot_be_inlined', not
`eval_method_uses_table'; it is just a coincidence that at the moment,
given the same eval_method the two predicates return the same boolean value.

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



More information about the developers mailing list