Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!seaman.cc.purdue.edu!ags From: ags@seaman.cc.purdue.edu (Dave Seaman) Newsgroups: comp.lang.fortran Subject: Re: What is the FORTRAN for ? Message-ID: <13393@mentor.cc.purdue.edu> Date: 28 Aug 90 16:25:43 GMT References: <13293@mentor.cc.purdue.edu> <61279@lanl.gov> Sender: news@mentor.cc.purdue.edu Reply-To: ags@seaman.cc.purdue.edu (Dave Seaman) Organization: Purdue University Lines: 91 In article <61279@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [Re: "a substantial bridge" = superintelligent loader] >Doesn't _have_ to be the loader. Many implementations have the >capability to do this sort of thing in the compiler. Some Pascals, >for example, have a way of declaring a routine to be a Fortran >external. If there were several different Fortrans on the target >machine, there is not reason not to have a distinct way of declaring >each. Since you say you are not trying to support both I/O systems, the alternate approach becomes more feasible. I can understand wanting to call Fortran routines from a Pascal program, but what is the point in trying to call one Fortran from another, especially when they are wildly incompatible? Isn't it easier just to recompile everything using a single compiler? My point in introducing the two-incompatible-Fortran examples was that you can't solve all the incompatibility problems by requiring all languages to be compatible with the vendor-supplied Fortran on the machine, because there may be more than one vendor-supplied Fortran, and they may be incompatible. I don't see how arranging to call one Fortran from the other solves compatibility problems with other languages. By the way, the compatibility problem is even worse than I indicated. It is reasonable to suppose that two Fortrans on the same machine will use the same representations for types INTEGER, REAL, COMPLEX, DOUBLE PRECISION and CHARACTER. The same does not hold for type LOGICAL. Beyond the requirement that LOGICAL variables take the same amount of storage as INTEGER and REAL variables, the standard places no restrictions on the internal representation and there is no single "best" way to implement the type. For example, one implementation may focus on the least significant bit, using 0 for .FALSE. and 1 for .TRUE. Another may focus instead on the sign bit, using +1 for .FALSE. and -1 for .TRUE. If there are arguments and common block variables of type LOGICAL that must be shared between the two halves of the program, your "substantial bridge" is going to have the devil's own time trying to tell them apart. >> 3. resolve name conflicts at load time caused by different routines >> being loaded from different libraries with the same name but >> different functions, > >This clearly doesn't have _anything_ to do with the subject we are >discussing. This problem can arise even if all the libraries and >main codes are writen in the _same_ language and for the _same_ >implementation. You misunderstood. The situation I described can arise within the same implementation when modules are used, but modules are not a part of pre-1990 standard Fortran, which is what we have been discussing. One of my examples was Fortran 77; the other was Fortran 66. There is no mechanism in Fortran without modules for a user even to force multiple routines by the same name to be loaded; normally the first one encountered is the only one loaded and all others are skipped. The problem also does not arise with runtime support routines in a standard-conforming implementation, because the implementor has full control over the namespace. Runtime support routines typically have nonalphabetic characters in their names in order to prevent collisions with the user namespace. When you mix two versions of Fortran, strange, new things can happen. Compiler A may have a runtime support routine $FOO whose purpose is to implement the ** operator for REAL operands. Compiler B may have a runtime support routine $FOO that repositions direct access files. When you mix routines that were compiled by both compilers, you are asking a lot of a loader that was designed without modules in mind to get both routines loaded and correctly associated with the calls appearing in both halves of the program. A user's program may have no visible references to "FOO" or "$FOO", but it still needs two different versions of the routine. I would mention the fact that compiler A has a different routine $BAR for repositioning direct access files, and that the two direct access routines will confuse each other if they operate on the same file, but you say you are not trying to support both I/O systems. Therefore, I won't mention it. >However, if you want to discuss this topic, I have a solution to propose. >Add 'module' support to your languages (as from Modula). And I suppose you think adding modules to an implementation that was designed without modules in mind will not take man-years of reprogramming? -- Dave Seaman ags@seaman.cc.purdue.edu