[m-rev.] for post-commit review: document and rename the force_versions set

[Julien Fischer]

On Tue, 17 Feb 2026 at 22:24, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Document forcing preds for type_spec pragmas.
>
> compiler/higher_order.specialize_in_module.m:
>     Document the meaning of a field.
>
> compiler/add_pragma_type_spec.m:
> compiler/hlds_module.m:
>     Change the code filling and using that field to avoid misleading
>     variable and predicate names. Add some extra documentation
>     where that can help.
>
> diff --git a/compiler/add_pragma_type_spec.m b/compiler/add_pragma_type_spec.m
> index 7924d2fe9..90e2ab95b 100644
> --- a/compiler/add_pragma_type_spec.m
> +++ b/compiler/add_pragma_type_spec.m

...

> @@ -371,15 +371,33 @@ find_pred_procs_to_type_spec(ModuleInfo, PredId, PredInfo, ProcTable, TVarSet,
>
>  %---------------------%
>
> -:- pred add_type_spec_version_of_pred(pred_id::in, pred_info::in,
> +    % add_forcing_caller_of_pred(PredId, PredInfo0, PredFormArity, TSInfo0,
> +    %     TVarSet, Types, ExistQVars, Constraints, SpecProcTable0,
> +    %     ApplicableModes, SpecPredId, SpecPredStatus, !ModuleInfo):
> +    %
> +    % The input parameters of add_forcing_caller_of_pred, including PredId
> +    % and PredInfo0, describe the predicate that has a type_spec pragma
> +    % for it, and the processed particulars of that pragma. Its job is
> +    % to add a new predicate to the HLDS that consists of nothing more than
> +    % a call to PredId with arguments whose types match the ones in the pragma.
> +    %
> +    % The point of this is that we already have code that traverses
> +    % the code of a module looking for natural (i.e. NOT programmer-requested)
> +    % opportunities for type specialization. By creativing the new predicate,

Unless you are intentionally creativing a new word there, fix that.

> +    % (whose id we return as ForcePredId) that contains a call that is
> +    % type-specializable in exactly the way that the pragma asks for,
> +    % we effectively reduce the problem of user-directed type specialization
> +    % to the problem of compiler-directed type specialization.
> +    %

...

> diff --git a/compiler/higher_order.specialize_in_module.m b/compiler/higher_order.specialize_in_module.m
> index d6b5455c2..5484effa7 100644
> --- a/compiler/higher_order.specialize_in_module.m
> +++ b/compiler/higher_order.specialize_in_module.m
>  %---------------------------------------------------------------------------%
> diff --git a/compiler/hlds_module.m b/compiler/hlds_module.m
> index e150b58a9..1257636a8 100644
> --- a/compiler/hlds_module.m
> +++ b/compiler/hlds_module.m
> @@ -129,16 +129,56 @@
>                  % specializations.
>                  user_req_procs      :: set(pred_proc_id),
>
> -                % Set of predicates which need to be processed by
> -                % higher_order.m to produce those specialized versions.
> -                must_process_preds  :: set(pred_id),
> +                % The set of forcing predicates.
> +                %
> +                % For each user-specified type specialization pragma
> +                % for a pred PredId, we create a new predicate ForcingPredId
> +                % that contains nothing but a call to PredId (in each of
> +                % the procedures that the pragma applies to).
> +                % When the code of higher_order.specialize_calls.m
> +                % traverses such calls, it creates the type specialized version
> +                % of PredId that the call asks for, which (by construction
> +                % of the call) will be exactly the same type specifialization

s/specifialization/specialization/

That looks fine otherwise.

Julien.