Path: utzoo!attcan!uunet!husc6!rutgers!bellcore!texbell!sugar!ssd From: ssd@sugar.uu.net (Scott Denham) Newsgroups: comp.lang.misc Subject: Re: Standardization (of FORTRAN, Ada, ect.) Summary: interlanguage communications, VAX, vendors Message-ID: <3014@sugar.uu.net> Date: 25 Nov 88 09:12:46 GMT References: <395@ubbpc.UUCP> <311@csun1.UUCP> Distribution: na Organization: Sugar Land Unix - Houston, TX Lines: 53 In article <311@csun1.UUCP>, weyrich@csun1.UUCP (Orville Weyrich) writes: > I think that this discussion points out a neglected aspect of programming > language development and language standardization: defining standard and > useful interfaces *between* languages, so that for example new code in modern > languages can be smoothly integrated into old programs written in old languages > without the need for massive rewrites. > > DEC demonstrates that this can be done in the VAX/VMS family of programming > languages (although this is a private DEC standard). > > Of course, such a proposal is not expected to be greeted with a warm welcome > by certain mainframe manufactures who have trouble getting their own standard > linkage conventions standardized :-), or those who have separate and > incompatible runtime libraries for each language :-), or those who do not > have language-independent code generators :-). > On the basis of conversations I've had with the language development folks from MY vendor, they'd like nothing better than to be able to do just that. But there are lots of issues, some of them pretty nasty. First, to take an existing environment in which all the languages work differently and move to a common library environment, somebody's got to change. Thats a nasty word around people with lots of "dusty decks" that they don't wnat to have break because sombody changed the way the library works in some subtle way. My understanding is that by starting more or less from scratch, DEC didn't have to worry about this so much with the VAX family. Secondly, there's the issue of "who's the boss here" when you have multiple languages involved - if a run-time error occurs, who takes care of it, and how? What happens when the standard or customary action is different between the two languages (E.G. fixed-point overflow in Fortran vs PLI). Again, a truly common linkage/library system might be able to address this by knowing exactly what sort of routine was in control at the time of the error, but that could get pretty messy, and expensive. Finally, in defining a common linkage convention, you have to allow for all the bells and whistles every language needs, or you have to be able to tell at compile time what sort of module you are linking to. This is likely to have nasty effects on linkage overhead from the standpoint of FORTRAN and C folks who are accustomed to quick, simple, and computationally cheap linkages. (This problem is not strictly a inter-language problem - making F77 and F8x get along will entail similar headaches). Now if we can just get around all that (and the stuff I have no doubt forgotten) we'll be cruisin'. I agree that if the environment worked well, a lot of the "multiple license" arguments would probably go away, and we'd also probably have a lot more professionals proficient in multiple languages. Scott Denham Western Atlas International Houston, TX > > What does the rest of the net think? > > -- > Orville R. Weyrich, Jr. | UUCP : ...gatech!ugacs!csun1!weyrich