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

[Zoltan Somogyi]

On 2024-06-30 14:42 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>> - 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.

Agreed; I got an error message about this ambiguity while
working on this diff.

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

In that case, the two things named some_int_const include just one cons_id;
the other is a type. Those don't substitute for each other.

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

du_ctor/3 is fine by me; for the other, 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.

Agreed.

And, in the early phases of the compiler at least, we have cons/1 used for
tuples as well, with the sym_name being {}. I am just now hunting a bug
involving tuples. It would be nice if at least one of the names alluded to
this possibility. I originally thought that this is possible only in too-long names,
but I just now thought of one: how about heap_ctor/1?

> * "ctor" is preferable" to "cons" as the latter is used in other contexts.

Well, we do have type_ctor, inst_ctor, and mode_ctor ... but the standard
FP/type theory terminology for what we want to represent is "data constructor",
so I agree that ctor is better than cons in this context.

Zoltan.