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

[Julien Fischer]

Hi Zoltan,

On Sun, 30 Jun 2024 at 13:53, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> 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.

To say nothing of the fact that several stdlib modules also have
predicate / functions
named cons.

> 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.

Having separate names didn't seem to be a consideration when some_int_const
was added.   If you have to have separate names, then I suggest the
arity 1 version
be called du_data_ctor and the arity 3 version be called du_ctor (see below).

> Some possibilities I have thought of for user_data_ctor/3 are
>
>   user_data
>   user_ctor
>   du_ctor
>   du_cons
>   du

I am inclined towards du_ctor, because:

* "user" suggests to me that the type in question is something that
was written by the user,
in their source code.  While this will be true in the great majority
of cases, it's certainly possible
that we may add code transformations to the compiler that introduce du types.
* "ctor" is preferable" to "cons" as the latter is used in other contexts.

Julien.