Xref: utzoo comp.lang.c:18369 comp.lang.fortran:2011
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Calling FORTRAN from C
Summary: Better ways to handle names
Message-ID: <1282@l.cc.purdue.edu>
Date: 4 May 89 16:07:04 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <10201@smoke.BRL.MIL>
Followup-To: comp.lang.c,comp.lang.fortran
Organization: Purdue University Statistics Department
Lines: 81

In article <10201@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <1278@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

			.........................

> Woo, woo, let's also insist on a LISP compatible interface.

Why not?  why should Fortran or C not be able to call a compiled LISP program?

> Let's also make C set up the run-time I/O support, activation contexts,
> garbage collection, etc. needed by other languages just in case we use
> them..

Each program better have its own I/O interface, etc.  There is a point in
having system ones with certain properties, but these are in the nature of
additional subroutines callable by the various processors.  I have had to
treat a Fortran-created file in C because the Fortran where the file was
being read did not have the Z format.

> >I have used several operating systems before UNIX.  On all of them, a name
> >was a name was a name.  The program cards and subroutine cards in Fortran
> >produced names in the object file identical to what appeared on the card.
> >Entry names and COMMON block names likewise.  Assembler-produced programs
> >did the same thing.  If I was going to use an Algol program it would still
> >be the same.  The calling sequence was a problem, even between Fortrans.
> >But not the names.
> 
> I don't suppose you ever named any of your functions Q8Q...?

Every system has its reserved words, including UNIX.  Every compiler 
likewise.

> Name clashes among external identifiers has been a practical problem
> ever since the invention of the link editor.

Agreed.  And they will continue to be.  Suppose several sources provide
routines designed to do the same thing.  You would need an object file
editor to handle the problem.  It should be provided.  But why should
Fortran, C, etc., have to have identical subroutines with different names
because of the namespace clash.

> UNIX had several constraints that caused the external name mapping
> conventions that it had.  One of them was a pre-existing assembler
> that had no way to prevent names such as "r0" the register from being
> confused with "r0" the external datum.

So rewrite the assembler so that the register r0 would be called !0 or
something similar.  Suppose there is reason to call a program sp?  The
register conventions would not allow this.  There are enough currently
illegal notations that one of them could be used for registers, where 
the problem is, rather than having everyone else do it.

>	  This caused the C compiler to
> give external identifiers an unmistakable form.  When preexisting
> assembly code was not an issue, as with the 3B series, the opposite
> approach of giving registers etc. unique name formats such as "%0"
> was followed and external identifiers were left alone.

This approach should have been followed everywhere.  Such changes to
assemblers are easy.  Even patches are easy, if a binary program 
editor is supplied.

> C and Fortran external identifiers could not be mixed (such as in
> implementing Fortran run-time support in C), due to differences in
> behavior expected for the same names.  For example, SUBROUTINE FOPEN.

So two functions with the same name should not appear in different
libraries?

> >Speaking of names, why should one not be able to name a main program?
> 
> Why add unnecessary complexity?

Because there can be reasons to refer to programs and entry points by
name when desirable.  Because people have used one program to operate
on another.  Because there are times when the same load process needs
to load more than one program which can be a "main" program.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)