Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!sri-unix!garth!phipps From: phipps@garth.UUCP (Clay Phipps) Newsgroups: comp.lang.misc Subject: Re: Linkage Declaration (was Re: Standardization (...)) Keywords: linkage,BLISS,standardization Message-ID: <2280@garth.UUCP> Date: 22 Dec 88 04:50:59 GMT References: <395@ubbpc.UUCP> <311@csun1.UUCP> <2086@garth.UUCP> <473@ihf1.UUCP> Reply-To: phipps@garth.UUCP (Clay Phipps) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 85 In article <473@ihf1.UUCP> bobd@ihf1.UUCP (Bob Dietrich) writes: >In article <2086@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >>Wulf attested to the high value of the [CMU linkage declaration for BLISS] >>but regretted the lack of a more complete solution. >>He concluded that he assumed that "the solution lies in getting >>an adequate characterization of ... the (rather vague) notion >>of `environment' explicitly into the language, together with >>primitive operators for its manipulation". >> >>...if only the standards committees for languages like FORTRAN, Pascal, >>C, &c. would translate something like this into ...those languages... > >...language standard committees have their own "turf"; >their charter usually precludes them from addressing areas >other than the language at hand. My suggestion to incorporate linkage declarations doesn't violate any turf any more than defining the "register" declaration for C does. If the committee charter limits its task to cleaning up, but not extending, the definition of the language, there isn't much I can do. >I don't want a language committee dictating what characteristics the >linker (if there is one) and the rest of the environment must take on, >although it might define certain minimal requirements. For probably any machine architecture, some combination of linker designers, compiler writers, and OS gurus design and implement the support provided by the OS, linker, and compiler for passing data around on a routine call (or other context change). As many of us are aware, individual choices are often made for various reasons by compiler writers that result in making their compiler incompatible with other compilers *for the same combination of hardware, OS, and linker*. Their alternative may be to impose a performance burden on one or more compilers for the sake of guaranteeing compatibility. After the machine begins shipments, there may even be a comfortable feeling that whatever incompatibilities exist will not be a problem in practice. Then in comes some marketeer with a customer that will hand over big bucks if only their big application, e.g., written primarily in Pascal, relying on FORTRAN math libraries, and accessing a data base server written in C, can be ported to our[*] machine. Another fine mess ... My particular concern was being able to describe *existing* linkage conventions, i.e., those already available in some compiler *for the same combination of hardware, OS, and linker*, when attempting to use routines written in different languages that call each other. Thus, the linker designers retain their freedom to determine linker and environment characteristics. My intent was not that all compilers be required to support all possible linkage mechanisms on all possible systems. A standards committee *would* need to devise a framework that covers linkage conventions used by members of its committee. It seems far better to me, that the standards committees lead the way than, as I understand recently occurred for Extended Pascal, for the committee to try (and fail) to reach a consensus among members who independently implemented a popular feature ("include files"), leaving it unstandardized for not just 1, but 2, standardization cycles. >If you've ever considered implementing something like fork() >on a non-operating system like DOS, >you wouldn't like to be forced in that direction by a language standard... My idea was to describe linkage that is already implemented, not to create language features as a substitute for absent OS features. The problems of arbitrary protocols, which was, perhaps, the reason for mentioning "fork", could be handled by a mechanism to name a transmitter routine, in the sense of Icon (or was SL5 first to have the feature ?). Let some OS guru write a transmitter routine to do the messy work. A transmitter might also be the best approach to allowing non-C calls to C routines expecting "varargs" parameters. The ambitious idea about manipulating environments was Wulf's, not mine. I incorporated them in the original posting because I considered his evaluation of his own (or own group's) features to be relevant, especially in terms of how effectively they resolved the problem in question. [*] The marketing situation described herein is hypothetical; any relation to actual marketing situations is purely coincidental. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800