[m-dev.] Tabling [1/3]

[Fergus Henderson]

On 10-Mar-1998, Oliver Hutchison <ohutch at students.cs.mu.oz.au> wrote:
> On Tue, 10 Mar 1998, Fergus Henderson wrote:
> 
> > > compiler/modes.m:
> > > 	Make sure that all procedures with non normal evaluation have 
> > > 	no unique/partially instantiated modes. Produce error messages 
> > > 	if they do.
> > 
> > Why?
> 
> I don't support partially instantiated modes because that's a boundary case
> that will require quite a bit of work.

OK, please document this with something in the log message and
with an XXX comment in the source.

> Does it make sense to memo a predicate with unique modes?

Probably not; but it would be good for your documentation to say that
it doesn't, and to explain why not.

> > > compiler/simplify.m:
> > > 	Only report infinite recursion warning if a procedure has
> > > 	normal evaluation.
> > 
> > I think it would probably still be useful to issue this warning at
> > compile time even if there is a `pragma loopcheck', because in general
> > compile-time warnings are better than run-time errors.
> 
> What about the case of memoing. It is then possible that the call will not
> lead to infinite recursion? 

I don't think so.  I think that a recursive call with the same input
arguments will still always lead to infinite recursion, even with
memoing.  Isn't that correct?

> > > +			{ pred_info_get_is_pred_or_func(PredInfo0, PredOrFunc) }
> > > +		;
> > > +				% XXX Fix this when we fix all the other 
> > > +				% XXX pragmas that dont properly support this
> > > +				% XXX case
> > > +			{ error(
> > > +"module_add_pragma_tabled: predicate and function with same name/arity") }
> > > +		)
> > > +	),
> > 
> > You should not call error/1 here.
> > What you ought to do to handle the XXX case is the same as
> > what all the other similar pragmas do: if there are multiple matching
> > names, apply the pragma to all of them.   (You can do this easily
> > by making the rest of this predicate into a separate predicate, and
> > calling that predicate for each element of the list of pred_ids returned
> > from predicate_table_search_sym_arity, perhaps using list__foldl2.)
> > 
> 
> It is my intention to fix this in a separate change.

Well, feel free to fix it differently with a separate change later,
but please fix it in the (very easy) way described above before
committing this one.

> I will make it
> possible to specify ether pred or func within the pragma declaration,
> something like :
> 
> :- pragma memo(func(blab/2)).
> 
> I expect this would be a good thing for all the pragma that suffer from
> the pred func ambiguity (most of them!)? For backward compatibility I would
> still allow the case where pred or func is not specified but would issue
> an error message if there was a clash.

Sounds good to me.

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