[m-dev.] New pragmas for tail recursion warnings
zoltan.somogyi at runbox.com
Fri Nov 13 17:46:36 AEDT 2015
On Fri, 13 Nov 2015 17:20:46 +1100, Paul Bone <paul at bone.id.au> wrote:
> > What I'd like to have reviewed at this stage are the names and syntax of the
> > pragmas.
> > % This pragma works on all procedures of a given predicate/function.
> > :- pragma no_warn_tail_recursion(NAME/ARITY).
> > % This pragma works on a single procedure.
> > :- pragma no_warn_tail_recursion(NAME(ARG_MODES*)).
> > :- pragma warn_tail_recursion(NAME/ARITY).
> > :- pragma warn_tail_recursion(NAME(ARG_MODES*)).
> Argh, I meant to say no_warn_non_tail_recursion and
> warn_non_tail_recursion, these match the option name
The predicate parse_arity_or_modes in prog_io_pragma.m
should parse either the NAME/ARITY or the NAME(ARG_MODES) syntax
for specifying a procedure or set of procedures. In the following,
I use PROC_SPEC as a shorthand for either.
I don't like the double negative in the name no_warn_non_tail_recursion.
I think it is very likely to confuse people, and even the ones who aren't
confused will not like having to take time to resolve the negatives.
I propose something like this:
:- pragma require_tail_recursion(PROC_SPEC, [OPTION_1, ... OPTION_N]).
where an option may be "warn" or "error" to govern what happens if
the requirement isn't met, or it may be "none", "self_recursion_only",
"mutual_recursion_only", or "self_and_mutual_recursion" to say what
kinds of recursion are required to be tail recursion, and maybe
"clique([OTHER_PROC_SPEC_1, ... OTHER_PROC_SPEC_N])" if the
user wants to specify what procedures the clique should have, so they
get a warning or an error if the clique accidentally becomes bigger
than what they expected.
That leaves the question of what the defaults should be; I propose
"warn", "self_and_mutual_recursion", and no of course no explicitly
We could also add an option that lists the backends on which
the requirement is valid.
Both your proposal and mine has to decide what happens if the
specified predicate has no recursive calls at all, and what happens
if it contains a higher order call (which may end up being a recursive
call, if the procedure's address is taken). I am pretty sure we would
have to ignore the latter, but the former is a different question.
More information about the developers