External names in other languages

[Paul Schauble]

I just received this item on the CP/M mailing list:

----------------------------------------------------------------------


[2202] (58 lines) PLS5.PDO1 01/14/85  0349.4 est Mon Info-CPM
Subject:  Re: an old idea whose time has come
Date:  Monday, 14 January 1985 02:32 est
From:  John C. Klensin <Klensin>
To:  info-cpm at AMSAA

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.
---[2202]---

----------------------------------------------------------------------

In view of the recent discussion here about using the ENTRY keyword to
provide an external name, I find this very interesting.

I would like to make a proposal for the new standard. As a basic part of
the standard, allow the construction

   identifier ENTRY "external_name"

in every context where identifier is visible beyond the current
compilation unit. For example,

   extern int current_date entry "SYS$DATE";

<identifier> is a normal C identifier in all respects, including length.
<external_name> is a normal C string constant, including processing
escapes such as \n \ \" and so on, whose meaning is implementation
defined. Two such declarations with the same external_string will be
matched by the loader.

This provides the means to reference naames defined in other languages
and permits a way around the length of external names problem. If this
feature is consistantly used, it will localize all system dependant name
requirements to the single declaration.

Comments??

          Paul Schauble
                    Schauble @ MIT-Multics.ARPA