Path: utzoo!utgpu!watmath!clyde!att!rutgers!deimos!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Standardization (of FORTRAN, Ada, e
Message-ID: <50500093@uxe.cso.uiuc.edu>
Date: 28 Nov 88 16:22:00 GMT
References: <311@csun1.UUCP>
Lines: 73
Nf-ID: #R:csun1.UUCP:311:uxe.cso.uiuc.edu:50500093:000:4855
Nf-From: uxe.cso.uiuc.edu!hirchert    Nov 28 10:22:00 1988


In an earlier article, Doug McDonald (mcdonald@uiucuxe.cso.uiuc.edu) ascribed
some positions to me that, unfortunately, weren't accurate, so let me clear the
record before I get flamed for things I didn't do or say.
1. Compatible calling conventions for all languages is not within the scope of
   X3J3 or any of the standards committees for specific languages.  There is,
   however, a separate committee that was investigating this area for possible
   standardization.  I do not know when or if anything will come of this work.
2. Even standardizing the interface between two specific languages is tricky.
   For example, one might be tempted to say that in calls between Fortran and C,
   one might be tempted to say that Fortran INTEGERs correspond to C ints.
   However, Fortran INTEGERs are required to be the same size as REALs, while
   C ints are expected to be the machines natural word size, so on some
   machines, this correspondence will not hold.  Again, this is not a topic
   that falls within the scope of standards committee for any single language.
3. What would fall within the scope of X3J3 would be some kind of statement,
   attribute, or processor directive to indicate that the external procedure
   one is calling was written in some other language (and thus may have
   different calling conventions).  I have proposed such features for Fortran
   8x (in various forms) and have supported proposals made by others, but no
   such proposal has won majority support from the members of X3J3.  There are
   a number of comments on this issue in the public comment, so I may prepare
   another proposal for next meeting.  (On the other hand, I'm getting married
   in less than three weeks, so I may be otherwise occupied.)

Now, in spite of my strongly supporting the idea of standardizing the
communications between languages, I do not see that as reducing the pressure
for much of what is in the Fortran 8x draft.  Most of the new functionality is
not of the sort that can readily be utilized merely by making procedure calls.
For example,
. I certainly wouldn't find it particularly convenient to have to call another
  language to execute a CASE statement or construct a non-counting loop.
. I would not find acceptable the need to call a procedure to reference
  dynamic storage, nor would I find acceptable the need to reference every
  dynamic objects through procedure dummy arguments.  (The overhead of the
  CALLs would kill performance.
. When working on machines with vector or parallel architectures, procedure
  calls are not acceptable as the sole means of accessing these capabilities.
  In many problems, the overhead would again be a killer.
. For obvious reasons, external procedures in other languages are not going to
  provide the functionality of internal procedures in Fortran.
Since the Fortran standard has always provided for the possibility of calling
procedures written in other languages, much of the pressure for extension was
in areas where this did not work well.

Some other random observations
. All the good examples of interlanguage communications that I have seen apply
  to single machine architectures.  I suspect it may be an order of magnitude
  more difficult to define standards for interlanguage communication that make
  sense across machine architecture boundaries.
. It may be politically difficult to get such standards adopted because many
  vendors may find it necessary to scrap or make major revisions to _all_
  their language products, not just those with new standards.  Furthermore,
  their new products, though compatible with each other, may have to be
  incompatible with their previous products.
. There is a big difference, in terms of training costs, between learning to use
  a new feature in a language you already know and learning a new language to
  make use of a comparable feature.
. Even if you are willing to spend the money, not all languages are available
  on all machines.  For example, there is no Ada compiler for the machine on
  which I currently program in Fortran.
. The question of the cost of supporting multiple languages is not as trivial
  as some have suggested.  If the machine is a central resource, the cost of
  acquiring another language may well be comparable to the cost of a major
  upgrade to an existing language, and in many cases this is likely to be a
  rather small part of the overall budget.  On the other hand, when one is
  dealing with workstations, the cost of supporting an additional language on
  each of several hundred machines can be much worse than the cost of even a
  major upgrade of the software already present on those machines, and this
  cost is likely to be significant relative to the budget for such machines.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications