[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