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