tsh@mace.cc.purdue.edu (Greg Kamer) (10/25/88)
> In article <909@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: > >I've written about this one before. MODULE is much more useful than > >INCLUDE if you are writing your code on a front-end machine and > >submitting it to a remote host. For such a setup, INCLUDE's > >have to be done with a front-end preprocessor before submitting the > >mainframe. With MODULE's you can simply prepend all of your MODULE's > >to the front of the code and send it off. > Could you clarify this a bit? It sounds as though you are saying that > all the MODULEs used in a program have to be part of the same compilation > source on the mainframe; that you can't have some MODULEs sitting there > that you just use. Is that so? > If it isn't so, how is having a module already sitting on the mainframe > and having the compiler use it any easier than having an INCLUDE file > already sitting on the mainframe and having the compiler on the mainframe > include it? (Remember COBOL's "COPY" statement, anyone? It can be done.) Think about HOW you would send stuff to another machine to compile it. 1) You would want ALL of your source code (including the stuff in MODULES) to be on your front-end machine. 2) You would want to cut down the amount of jcl required on the mainframe to obtain the source code for compilation and you would want a setup where YOU don't have to remember to upload the source code to the mainframe for a particular MODULE and/or source code routine once you have made changes. (Let's see, out of those 92 source code files and 27 INCLUDE files, which ones did I change in the last 2 days of sweeping mods. Seem familiar?) The point is that you don't want to do source code maintenence on the mainframe, thus the MODULE's would be on the front-end. Also, you need to remember that SOME operating systems (such as CDC VSOS, which is what we use on our Cyber 205) differentiate between local job files and permanent files. Thus, you must inlcude jcl to pre-attach and INCLUDE or MODULE files that you might have on the mainframe BEFORE you run the compiler. Lets say I have 4 INCLUDE files on the mainframe- then the required jcl (assuming that you have a compiler which will deal with INCLUDE files - the Cyber 205 compiler does NOT) would look something like ATTACH include-file-1 ATTACH include-file-2 ATTACH include-file-3 ATTACH include-file-4 upload-source-code-from-front-end FORTRAN,INPUT=source-code-file LOAD EXECUTE Those attaches can get pretty darned tedious for programs that have a lot of INCLUDE files (some of our programs have over 20 of 'em). Now lets see what we get if we have them all in a single MODULE file. ATTACH module-file upload-source-code-from-front-end FORTRAN,INPUT=source-code-file LOAD EXECUTE This requires less jcl, but it still means I have to remember to upload the MODULE file(s) if I have changed them. This is a real good way to get burnt! Now lets take a look at my current setup. This involves having all of the source code on the front-end, so *I* don't have to remember to upload anything when they are changed. On the front-end - concatenate and pre-process the source code to pull in INCLUDE files append this to the end of the jcl required to compile and load, telling the compiler to obtain its source from std input. submit the result to the mainframe What the mainfram sees is FORTRAN,INPUT=INPUT LOAD EXECUTE (end-of-group) pre-processed source code Note that this requires me to write or obtain a pre-processor that will pull in those include files. If the MODULE concept is enabled, we get On the front-end concatenate the MODULE files followed by the source files append this to the end of the jcl required to compile and load, this time telling the compiler to obtain its source from std input. submit the result to the mainframe What the mainframe sees is FORTRAN,INPUT=INPUT LOAD EXECUTE (end-of-group) MODULEs source code and this time no silly pre-processor is required. The main point I was trying to make is that for situations where your compiler is on a different machine the MODULE command cuts down on either the amount of jcl required to obtain the source code and/or eliminates the need for a front-end preprocessor. The disadvantages of INLCUDE .vs. MODULE are glaringly apparent to anyone who has ever worked on a system which differentiates between local job files (which are available to the executing job) and permanent files (which require jcl to make them available to the executing job). I suspect that you have never worked with such a setup- most people I talk to who have never dealt with such an environment have difficulty in understanding why the compilers on such systems don't have INCLUDE facilities. Its because using INCLUDE's on such a system would require lots of tedious jcl and better ways have been devised to deal with the facility for such operating systems, usually as part of a source code revision control system. Alas, the 205 is a miserable interactive environment, and so we don't even use the revision control system (UPDATE) available on the 205 since the facilities available on our Unix front-end put it to shame. Now if they would just add a macro facility to Fortran 88.... -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/26/88)
In article <917@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: stuff removed... The point is that you don't want to do source code maintenence on the mainframe, thus the MODULE's would be on the front-end. Also, you need to remember that SOME operating systems (such as CDC VSOS, which is what we use on our Cyber 205) differentiate between local job files and permanent files. Thus, you must inlcude jcl to pre-attach and INCLUDE or MODULE files that you might have on the mainframe BEFORE you run the compiler. More Cyber stuff ... I agree that MODULE is very useful. But the issue of distributed source can be handled at the distributed OS level quite nicely. (* sun plug follows *) NFS + automounter + yellow pages + NSE. (all sun products, many of which exist on other vendors platforms, thanks to licesening agreements) (* end sun plug *) Naturally this does not help those working with machines whose vendors haven't climbed onto the bandwagon! :>>> My points are: 1) MODULE has other good features. It should be implemented. 2) Source code control/network stuff can/should be done at the OS level. btw: > "...macro-processor in f88" This got lost very early in the comittee. To make a long story short, the committee felt under pressure to keep the proposed standard fairly short. So macro-processing we left out. I would have preferred it be included; but it is too late for f88. Let's ordain f88, and work on implementing it. Then in five years we can start discussing f9x, or f20xx. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
ok@quintus.uucp (Richard A. O'Keefe) (10/26/88)
In article <917@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: >Think about HOW you would send stuff to another machine to compile it. My method of choice would be NFS, actually (:-). >2) You would want to cut down the amount of jcl required on the mainframe > to obtain the source code for compilation and you would want a > setup where YOU don't have to remember to upload the source code > to the mainframe for a particular MODULE and/or source code routine > once you have made changes. (Let's see, out of those 92 source code > files and 27 INCLUDE files, which ones did I change in the last 2 > days of sweeping mods. Seem familiar?) Yes, it seems familiar. That's what "make" is for. It's an idea which has been invented many times, and is quite easy to do. (For UNIX, there is even a public-domain tool to make make-files automatically.) Why should I care how much JCL there is as long as it is generated automatically? >ATTACH include-file-1 >ATTACH include-file-2 >ATTACH include-file-3 >ATTACH include-file-4 >upload-source-code-from-front-end >FORTRAN,INPUT=source-code-file >LOAD >EXECUTE > >Those attaches can get pretty darned tedious for programs that have a >lot of INCLUDE files (some of our programs have over 20 of 'em). So what? Who would dream of writing that stuff by hand? Ok, so the mainframe may make script-writing hideously complicated, but we're already talking about something like PWB where the source maintenance and script generation is done automatically on a front-end machine. Given the choice of writing a tool to generate the JCL automatically to attach files which are already sitting on the mainframe, or having to collect all my source files into a single giant document and transmit it, I would much rather do the former. (If I want to compile on a /370 from here, we have to pay for the time it takes to transmit the sources, and that is not especially cheap. I really do not want to upload anything which has not changed.) >Now lets see what we get if we have them all in a single MODULE file. Ahah! So you *are* saying that the MODULE facility requires a single great big lump of source. Doesn't that sort of miss the point of Fortran? >Note that this requires me to write or obtain a pre-processor that >will pull in those include files. So? That's half an hour's work in UNIX+C, two hours' work in VMS+FORTRAN. >The main point I was trying to make is that for situations where >your compiler is on a different machine the MODULE command cuts >down on either the amount of jcl required to obtain the source code >and/or eliminates the need for a front-end preprocessor. I still don't understand this. It does so *only* if you intend to compile your programs on the mainframe as single large files. This is not the way modules work in MODULA-2 or packages work in ADA or separately compiled classes work in SIMULA-67. I thought the idea of modules in F8X was to permit type-checked *separate* compilation (but not of course to require it). And I want to stress that if the mainframe you are using is not on-site, you have to balance the cost of transmitting unchanged source files again and again against the cost of renting disc space for them, and sometimes the latter approach is cheaper.
mcdonald@uxe.cso.uiuc.edu (10/26/88)
I believe that the MAJOR problem with module as opposed to include is that what can be placed in a module is limited. ANYTHING and be placed in an include. In any case, since include is present standard practice, it must be included (sorry for the pun) in any useful compiler anyway - so if it is not in the standard, people are going to laugh at the standard.
maine@pioneer.arc.nasa.gov.arpa (Richard Edwin Maine D-OFA) (10/28/88)
Several recent postings have debated the merits of the Fortran 8x modules. My nickel's worth follows. These are all opinions based my personal experience, about which I feel well qualified to talk. I make no claim to represent the elusive "typical" user. By the way, I am a user who does numerical applications for flight data analysis. I also spend a lot of my time helping other users write and debug code. I "confess" to having worked towards a PhD that I never finished, but it was in engineering instead of computer science, so that's ok.:-) Modules are one of the parts of Fortran 8x that I was most pleased to find on reading the draft standard. There were other good things too, but modules were certainly high on my yes list, close behind data structures. These are some of the kinds of features that have occasionally driven me to use languages other than Fortran. I may even be forced to go to ADA(tm) if Fortran 8x doesn't happen sometime in the reasonably near future; please save me from that! Some of the postings have discussed modules versus include statements. This comparison seems to ignore most of what I thought, IMHO, that modules were about. (Ok, tell me I'm wrong, but politely, please; my mother is really quite a nice lady:-)). To me, the biggest thing modules are about is modularity. (Thus the funny name, right)? This means program structuring, information hiding, and lots of good buzz words like that. There was a time when I didn't care much about that kind of stuff, as long as I could compute the correct numbers. As the years have passed, this has changed - a lot. Maybe I've just gotten lazy and don't like to spend so much time debugging and maintaining the codes. Some of my colleagues will claim I'm just getting senile (at the tender age of 37 - alas). I prefer to think of it as maturing my programming style, and I'd like to see the language mature also. I won't try to write a treatise on information hiding. Others have done it far better than I can and at more length than is appropriate here. Let me just say that it is really true that it helps create more reliable programs that have better odds of actually computing correct answers. I've killed many a bug from related causes in code written by many people (myself included). Conversely, I've found there have been far fewer bugs to kill in my own code, once I got "religion" and started paying a lot of attention to modularity and localization of information. Yes, you can do it in Fortran 77, but the language fights you every step. If you try to substitute include statements for modules, you tend to get zillions of unneeded variables available to many routines unless you work very hard at structuring the include files to avoid it. Furthermore, you do not see the names of these variables when you are editing the main source file (or when looking at the listing file if the include files are omitted from the listing, which they sometimes are). Add the fact that the include file may have been written by somebody else and you have almost guaranteed disaster. This happens for real; I've seen it. Just like modules help hide information that should be hidden, they help communicate information that should be communicated. I think of modules as more of a replacement for COMMON blocks than for include files. (Though I do agree that if you do use COMMON blocks, which you need in Fortran 77, you should certainly do so with include files). COMMON blocks are burdened by too many strange restrictions and are long overdue for overhaul. COMMON blocks cannot have constants (though it is true that the include file containing the common block may have symbolic constants; mine usually do). COMMON blocks cannot be initialized except in Block Data, which have a host of queer system dependent problems. COMMON blocks are inextricably linked to memory association, which makes it tricky to introduce very useful things like dynamically allocated arrays. (I don't see how include files are going to help you make globally accessible dynamically allocated arrays without modules unless you introduce some other new language features). Furthermore, many users are completely unaware of the quirks of common blocks and this gets them in trouble regularly. I have had many other users come to me complaining that xyz brand (it varies) compiler is broken because, for instance, it won't compile this data statement. They are almost uniformly shocked when I tell them that the data statement won't compile because it is illegal. After all, they always used to do things like that on abc brand (also varies) compiler, so it must be legal. Include statements often cause long compile times also. Try writing a sizable graphics program that you have carefully modularized into 100 or so small routines averaging 50 to 100 lines each. The vendor of the graphics package you are using has provided an include file about 1,000 lines long defining the various goodies needed for calling the graphics package. Since Fortran 77 has no concept of global definitions, this include file must be included in every routine that needs anything in it. This does obscene things to the compilation time (in addition to inviting bug infestations). I did not make this scenario up; I've seen it often. My usual countermeasure to the 1,000 line vendor-provided include files is to extract just those definitions needed for my code into my own smaller include file. However, this is 1) tedious; 2) a maintenance headache; 3) an extra place for typographical or other errors; and 4) just not applicable in some cases. It is true that you can commit the same sins with modules and that you can make good use of include files. I use include files now, and I try to use them well; they beat the heck out of manually putting (almost) identical COMMON statements in each routine. My point is just that modules make it easier to do the job better. Yes, I'll confess that I'd like to see a virtually new language. "If this be treason, make the most of it." - Patrick Henry. Some of the things I would most like to see dropped from Fortran 8x are some of the old features retained only for downward compatability. Yes, I know lots of people disagree. Ok, keep the features in the language, but I won't be using them. We already have a language for those who think that Fortran 77 is perfect. (Or even that the bugs in the previous version of their favorite vendor's compiler were features that should not have been removed in the current version. Yes, I've seen complaints like that, and more than once). What we do not have is a language for scientific work that combines good error detection, clear syntax and power of expression, efficiency, and portability. It isn't Fortran 77. (The language of "DO 10 I = 1 100" and "IF (X) THEN A=1"). It isn't c. (Some of my friends think otherwise, but it isn't for me). It isn't Pascal or Modula. (As in "You want a what kind of array? Well, if you insist, our compiler has a special extension that..."). It isn't ADA. It isn't anything else that I know of, and I've tried a pretty wide variety. Fortran 8x isn't perfect either (what is?), but it could be a lot closer than any of those others. IF it happens, that is. I'd like to see it and I'd be happy with the WG5 proposal or something close to those lines. And, of course, I'd like to see it no later than a year ago, if not earlier. Gosh, all the time I've been wasting by using inferior languages. Richard Maine NASA Dryden, Edwards, Cal. maine@pioneer.arc.nasa.gov - internet maine@elxsi.dfrf.nasa.gov - preferred, but our internet conection is only about a week old, so the other address might be safer.