Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.misc,comp.lang.c,comp.lang.fortran,comp.lang.pascal
Subject: Re: Names of non-local objects
Message-ID: <6173@brl-smoke.ARPA>
Date: Sat, 25-Jul-87 05:16:37 EDT
Article-I.D.: brl-smok.6173
Posted: Sat Jul 25 05:16:37 1987
Date-Received: Sat, 25-Jul-87 22:04:49 EDT
References: <557@l.cc.purdue.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18
Xref: mnetor comp.lang.misc:581 comp.lang.c:3278 comp.lang.fortran:173 comp.lang.pascal:211

In article <557@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>This would enable the user who, for some reason,
>wishes to combine programs from different compilers not to have to worry 
>about what mangling of names is done by this compiler on this system.

There is a lot more to worry about than simply matching of external
names by the linker.  Inter-language linkage can be quite tricky,
although some vendors have made a stab at supporting it (notably
DEC's VMS).  The problem is basically that different languages can
pass objects between procedures that other languages cannot handle.

The external name space available to the programmer is already quite
badly hampered by having to avoid conflicts with system library names.
It would be much worse if one had to worry about conflicts with all
possible languages on the computer!  I for one am much happier with
Fortran names not colliding by accident with C names; for one thing,
it makes it possible for a Fortran support library to be written in
C, as many are.