[m-dev.] I need names for a cons/3 replacement

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun Jun 30 13:52:48 AEST 2024


I am just finishing up a diff that fixes an issue we had
with the cons/3 function symbol in the cons_id type for ages,
which is that several parts of the compiler operate *only*
on these cons_ids, and not on any other cons_ids, yet
they had to be prepared to handle these others as well
*somehow*.

At the moment, the diff adds a new type named user_data_ctor
whose definition is

:- type user_data_ctor
    --->    user_data_ctor(sym_name, arity, type_ctor).

and turns the cons/3 cons_id into cons/1, with the argument
of course being of type user_data_ctor. Due to the direct_arg
optimization, this change should have no effect on the amount of
memory required to represent a cons_id.

Preparing the diff for review requires renaming several
predicates that previously operated on cons_ids and now
operate on user_data_ctors. I would prefer to do this renaming
just once, not once before review and once after review,
after someone proposes a better name, so I am asking for
any better names now. I am asking about both

- the name of the new type, which should also be the name of its
  one function symbol, and

- the name cons/1 itself. This is also *almost* the name of its type,
  but in this case, that is a bad thing, since there are other kinds of
  cons_ids as well.

These should be two separate names, because having the same name
for both these purposes, differentiated only by arity (1 vs 3) means that
any errors in code that uses both (which will be most code that uses either)
will result in less useful error messages than if the names were different.

Some possibilities I have thought of for user_data_ctor/3 are

  user_data
  user_ctor
  du_ctor
  du_cons
  du

All these would work, with arity 1, for cons/1, as of course will "cons" itself (sort-of).

Anyone have any ideas for better names? Or opinions on which of these names
they would prefer in each role?

Zoltan.


More information about the developers mailing list