Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!usc!apple!genbank!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN 8X PRECISION (MORE) Message-ID: Date: 14 Nov 89 18:16:01 GMT References: <7662@xenna.Xylogics.COM> Sender: news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 54 In-reply-to: mvs.draper.com@RELAY.CS.NET!PDM1881's message of 13 Nov 89 15:51:41 GMT In article <7662@xenna.Xylogics.COM> mvs.draper.com@RELAY.CS.NET!PDM1881 writes: > .... Then it was pointed out that this is solved by INTERFACE > blocks in 8x. Well, I don't want interface blocks, but I agree that > this is the right approach. What I would prefer, is to extend the > syntax of the EXTERNAL statement, for example, a routine calling > REAL FUNCTION FUN (X, I) > could contain > REAL FUN > EXTERNAL FUN (REAL, INTEGER) > Furthermore, such statements could be included in the function (or > subroutine) itself, for the compiler to verify. > I greatly prefer extensions to the existing structure of the language, > to the kinds of changes proposed by X3J3. But what you have is little more than an interface block masquerading under another name. And unfortunately, yours is not as general as the proposed 8x one. It is far from trivial (in fact, its downright difficult) to come up with language constructs that fit well in all possible contexts of something like Fortran. Although I was not part of it, I can well appreciate the amount of work that somebody on X3J3 had to do to avoid a standard that was full of inconsistencies and ambiguities. (There are bound to still be a few, nothing being perfect, but on the whole a lot of care for such issues is apparent in the draft). For instance, how does your suggestion handle even such 77 constructs as a subroutine that takes another subroutine or function as an argument. One could probably invent some syntax for that, but it's likely to be rather kludgy. (And I hesitate to even think about how to incorporate things like data structures in your syntax). The proposed 8x interface blocks are general enough not to back us into something difficult to extend. Also, keep in mind, that interface blocks are not generally required if you use modules. For module routines, the interface information is already avaliable and you really have to do nothing extra (except for declaring the module in a USE statement). The interface blocks are needed only in special situations where you can't use modules. Generally, lots of things in 8x are much cleaner if you use modules. I would categorize modules as the most important change/improvement in 8x and a lot of the other changes are related. If you don't like modules, then I can understand that you aren't going to like 8x because they are integral to the language. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1]