On Aug 15, 2020, Nathan Sidwell <nat...@acm.org> wrote:
> 'alias' is also now a confusing term, because of the concept of
> object-aliasing.
True, but it's also an established attribute name. It seems thus
desirable to bring the conceptual framework of the alias attribute to
mind through the name of the attribute used in this new feature, but
with a twist that distinguishes it from the original attribute in a
meaningful way.
> The existing alias attribute is defined as:
>> The @code{alias} attribute causes the declaration to be emitted as an alias
>> for another symbol, which must have been previously declared with the same
>> type, and for variables, also the same size and alignment. Declaring an
>> alias
>> with a different type than the target is undefined and may be diagnosed. As
>> an example, the following declarations:
> I.e. it is creating a declaration that is aliased to some other symbol
> (which has to also be emitted by the same TU due to the usual elf-like
> object file semantics). Notice it says nothing about emitting a
> *symbol*.
It's an implied expectation that declarations of language entities get
symbols associated with them, and that attribute alias causes the symbol
name associated with one declaration to refer to the same entity denoted
by the named symbol, instead of introducing a separate entity.
> The new attribute is emitting a symbol that equates the declaration it
> is attached to (i.e. the other way round).
I.e., now we have a single declaration of a language entity, and we wish
additional symbol names to be associated with it.
> Its intent is to allow code written in another language to refer to
> this definition. I imagine you'd commonly use the foreign language's
> mangling for the string provided.
What I have in mind are mnemonic, user-chosen names, rather than
machine-mangled ones.
> If we spell it 'X', consider:
> [[gnu::X ("other")]] int i;
> Most commonly, the assembly emitted would contain:
> .globl other
> .equiv other, i
> so, perhaps we should spell it 'equiv'? That's using an existing term.
Uhh, my turn to find the term meaningless. Not just because on my
machines, aliases use .set rather than .equiv. It's missing about as
much context as 'aka' and 'nickname' in the relationship to alias.
The problem we face is that alias is a symmetric relationship, in that
if X aliases Y, then Y aliases X, but attribute alias is not symmetric:
its attribute must be placed in an undefined declaration, naming the
already-defined entity.
It would have made just as much sense to make it work backwards, namely,
attaching the attribute to the defined entity, naming any other
undefined declarations that ought to refer to the same entity. That's
pretty much the attribute I propose.
Thus clearly, though "alias" is symmetric, our use thereof isn't. Our
implementation uses the phrase "alias target" to refer to the
already-defined entity that a declaration holding an alias attribute
should alias; the declaration holding the alias attribute is referred to
as an alias.
Since attribute alias is already taken, it would thus make sense to look
for opposites of alias target to denote the new attribute. Alias source
and alias origin are probably the most natural opposites of alias
target, but they don't suggest to me what we're looking for. Alias lead
might work. Alias bead might, too.
OTOH, since the alias attribute is associated with the alias
declaration, and it names an alias target; the opposite of that, with an
attribute in the alias target declaration, would best have the attribute
named alias_target (that's an attribute of the declaration, after all),
and then the named symbol would be the alias. This would be
surprisingly consistent with the current use of attribute alias:
int attribute((alias_target("Y"))) X; // X is the alias target for Y
int attribute((alias("Y"))) Z; // Z is an alias for Y
Now, if we were to use "equiv", it would make sense to think of the
current alias attribute as "equiv_to" / "alias_target".
Another possibility that occurs to me is to reuse the existing attribute
alias, but naming the equivalent symbol as a second parameter to
attribute alias, suggesting a relation alias(X,Y), building on the
existing alias(X) in which the Y is implied, and introducing a variant
in which it is the X that is implied. Alas, an explicit placeholder is
needed in this case.
Hmm, maybe such a two-argument variant of alias could be made more
readable by requiring the *second* argument to be number 2:
int attribute((alias("Y", 2))) X;
reading as imperative "alias Y to X", whereas existing uses:
int attribute((alias("Y"))) Z;
read as imperative "alias Y Z", nonsense, but taken as "alias Z to Y",
perhaps by analogy with how "give Y Z" is taken as "give Z to Y".
/me jokingly suggests inhalias and exhalias ;-)
This is enough bikeshedding for me ;-)
--
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer
