[m-rev.] for review: encode arity kind in the type in pred lookups

Julien Fischer jfischer at opturion.com
Tue Feb 22 23:50:36 AEDT 2022


On Tue, 22 Feb 2022, Zoltan Somogyi wrote:

> Encode the arity kind in the type in pred lookups.
> 
> compiler/pred_table.m:
>     Some predicates in this module have traditionally taken an arity argument
>     that *included* function result arguments, while others took an arity
>     arguments that *excluded* function result arguments. While the difference
>     was documented, it was not enforced in the types. Change this by
>     switching the two kinds of arities to pred_form_arities and user_arities
>     respectively.
>
>     Change the internal data structures to specify in the types
>     that they operate on user_arities.
>
>     Change the operation of lookup_builtin_pred_proc_id as part of the
>     change to goal_util.m (described below).
> 
> compiler/goal_util.m:
>     When looking up the pred_info of a builtin, caller used to pass to the

s/caller/callers/

>     predicates that did that (generate_simple_call and generate_foreign_proc)
>     a list of the arguments of the call without specifying which arguments
>     were type_info/typeclass_info arguments added by polymorphism.
>     This meant that the length of the argument list was *not* necessarily
>     the called predicate or function's pred form arity, but could exceed it
>     by the number of arguments added by polymorphism. The only reason this
>     worked was because the lookup_builtin_pred_proc_id procedure they used
>     to look up the named predicate in the pred table compensated for it

The rest looks fine.

Julien.


More information about the reviews mailing list