[m-dev.] pragmas should specify pred/func as well as name and arity

[Julien Fischer]

Hi Zoltan,

On Thu, 29 Apr 2021, Zoltan Somogyi wrote:

> I can see three broad approaches to how this could be done.
>
> Approach 1 would be to wrap the name/arity pair in either pred() or func().
> This would look good, but unfortunately the second syntax also uses terms
> whose top function symbol is either pred or func, and there are some pragmas
> that allow the subject that they apply to to be specified using either the first
> or the second syntax (see attached table), so this would probably serve
> as a source of confusion. And the compiler's error messages, having to
> describe two possible ways to fix any syntax errors (one to reach each kind
> of valid syntax), couldn't help as much as we would like them to.

I think that a very strong argument in favour of approach 1 is this: it
is the syntax we already use in other parts of the language,
specifically out-of-line method definitions in type class instances are
written as:

     :- instance foo(...) where [
        pred(methodname/arity) is predname
        func(methodname/arity) is funcname
     ].

If possible, I think we should avoid having multiple ways of identifying
predicates / functions in the language.

> Approach 2 would be to add a "_pred" or "_func" suffix to the pragma name,
> such as ":- pragma inline_func(foo/2).". We have already used this approach
> when replacing ":- external(foo/2)." with ":- external_{pred,func}(foo/2).".
> However, there are some pragmas, such as "terminates", for which neither
> that suffix, nor a similar prefix, would look all that natural.

Having a prefix "pred_" or "func_" might work with terminates, but it's
still a bit ugly.

> Approach 3 would be to add an extra  argument, containing simply either
> "pred" or "func", to the pragma's argument list, just before the argument
> that now contains just foo/2.

That's actually what several of the generated pragmas (e.g. exceptions,
trailing_info) do now.  (Except that they output "predicate" or
"function" rather than "pred" or "func".)

> There are also blended approaches: we could require a suffix such as "_proc"
> for pragmas that specify the argument modes, a form of approach 2,
> and then require a pred() or func() wrapper for the form of the
> pragma that does not specify modes, i.e. approach 1. The point of
> separating out the _proc form is to mitigate the error message problem
> described above. As the attached table shows, only a few kinds of pragmas
> allow the subject of the pragma to be *either* a single procedure
> or all procedures in the named function or predicate.
> For example, we could replace the type_spec pragma with three
> others: type_spec_pred and type_spec_func when you want
> type specialization for all modes, and type_spec_proc when you want it
> for just one.
>
> There is also what we might call "approach 0": simply obsolete the pragmas,
> such as promise_pure, whose effect can be accomplished by wrappers
> around goals.
>
> Does anyone have any other approaches to fixing this problem?
> And what are your preferences?
>
> It would be simplest if we chose the same approach for all pragmas,
> but we could adopt different approaches for different pragmas.

Ideally the pragmas intended for users should converge (eventually)
on the same approach.  (The generated ones should do whatever allows
them to be most efficiently and unambiguously processed.)

> We would need to introduce any such changes gradually. We would
> implement any new syntax alongside the old, generating messages
> telling programmers to switch to the new form when we find the old.
> These messages could have severity warning, but with an option to
> shut them up, such as --no-warn-for-old-pragma-syntax. That would
> need to persist past the next stable release, after which we could
> first up the severity to error, and then later still disable the code
> parsing the old syntax altogether.

It will need to be done very gradually, over several releases.

Julien.