"John C. Klensin" <Klensin@MIT-MULTICS.ARPA> (01/14/85)
Let me add two things to this discussion, which may or may not be
helpful:
The *equat feature of the 1130 linker also appeared in an early version
of the OS/360 "linkage editor", with the keyword CHANGE (If I recall)
and a slightly different syntax. This feature has been carried forward
into subsequent versions of the related operating systems, so it was not
an idea that appeared and disappeared because almost no one found it
interesting. Note, however, that as soon as one generalizes the
characters that can appear in some places and not in others, that the
linker (or whatever) needs special syntax, like quoting characters, to
delimit strings that might otherwise not be acceptable to it [either].
Although sharing some sympathy for the linker plan, I see it more as a
useful mechanism for patching things up at the last possible moment than
as a good solution. A better solution involves seeing it as just
another case of binding the semantics of a name in a program (e.g.,
something that obeys the C (or whatever) naming rules to that name,
where the "external" form, whether longer or of a different case or
symbol structure, is just part of the semantics. A near variation of
the problem that illustrates the point appears when you think, not of
"how to get a $ into a name", but about inter-language procedure calls
(or external (global) variable references of other sorts) where two or
more statically compiled languages have different rules about the naming
of such variables.
ANSI X3J1 (PL/I) had a long series of discussions on this one a year or
two ago in the context of languages that supported case sensitivity in
identifiers and operating systems that did not, languages that didn't
and operatings systems that did, and languages that had "everything goes
to upper" mapping rules and those that preserved case sensitivity. The
conclusion was that, while it was probably a good idea to have some
name-changing and mapping linker facilities also (whatever that might
mean in a host independent way), it should be possible, for a number of
reasons, to make these bindings at compile time also. Unless the
committee changes its mind (very unlikely, but I am obligated to say
things like that), the next version of the PL/I standard will go out for
public comment with an optional extension to the syntax for external
names, in the form of
EXTERNAL (...)
s.t., in a particularly bizzare case, you might write
dcl sub1 external("avery_long$name_with_all_sorts#@%^&of NONSENSEinIT");
what goes between the parens is, clearly, an implementation-dependent
and otherwise unrestricted character string. It can even be a character
variable, as long as its value is known at transation time.
It is also pretty easy to implement, even if only by preparing, and
passing along, a few instructions to the linker as part of the
translator's output.
Note also that this type of approach permits either name (or, if the
capability is otherwise available, both names) to be made available in
the symbol table, since the translator has all the information available
when the symbol table is constructed.