[m-rev.] for review: pragma input_spec

[Julien Fischer]

On Fri, 14 Aug 2026 at 19:28, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>> On Fri, 14 Aug 2026 17:56:27 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> > > +input_specialize_in_module(!ModuleInfo) :-
> > > +    module_info_get_input_spec_table(!.ModuleInfo, InputSpecTable),
> > > +    module_info_get_valid_pred_ids(!.ModuleInfo, PredIds),
> >
> > Won't this apply this transformation to uci preds and other compiler-generated
> > predicates?  Is that intentional?
>
> Yes, in the current form of the diff, it will apply to uci preds, and
> no, this was not intentional.
>
> Most of the time, the type to be input specialized is an enum type
> that does not actually need an uci predicate, because values of that type
> would be unified only with constants, which are deconstruct unifications,
> and therefore do not invoke the type_ctor's unify predicate. And they
> are not compared either. Creating input-specialized versions of the type's
> uci predicates is therefore wasteful in that it creates more unused procedures
> for dead-proc-elimination to get rid of, but it does not lead to bloat.
>
> On the other hand, if some unusual code *did* unify some such values,
> then the input-specialized versions could have tighter determinisms
> (either failure or det) than the non-specialized versions (semidet).
>
> I lean towards not input specializing uci preds. You?

Likewise, but it's not just uci pred, mutable access preds are another
example.

> > This seems suspicious. The HLDS has a lot of references to proc_ids.
> > Why does this renumbering not invalidate the ones in, for example,
> > the list of pragma exported procs?
>
> I didn't think of that. However, foreign_export pragmas specify
> the procedure to export by giving a vector of the argument's modes,
> not by mode number, so renumbering should not be a problem.
> The same should be true for rest of the language, since no part of
> Mercury syntax allows code to refer to mode numbers.
>
> The replacement of an exported mode is something we could detect,
> though it would require processing all foreign_export pragmas
> before any input_spec pragmas, which we do not (yet) do.
>
> There are some other pragmas (such as external and obsolete)
> that also refer to procedures by argument vector modes.
> We would want to check for them as well. However, I don't think
> any non-pragma part of Mercury allows such references.
> Do you know of any?

Off the top of my head, no -- I would need to look.

> Thanks for the review. As for the next steps: I can either commit what I have,
> unresolved correctness arguments and all, or wait until all such issues
> have been reviewed and resolved. I favor the first approach, because
> it makes creating diffs easier and more reliable, and the presence of any bugs
> in a construct that noone knows about and therefore can't use will not
> be detectable. What do you think?

I am fine with you committing it now.

Julien.