reeder@ut-emx.UUCP (William P. Reeder) (03/11/88)
In article <6690013@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes: > uncheckable dependent compilation. With MODULEs, the revision date can > be checked by the compiler between the source and the preprocessed module > to ensure that your compilation is consistent. Well, I'm not sure what you mean about checking the revision date on a MODULE. Could you explain further, also discuss why this also can't be done with INCLUDE files (pretend I don't have to deal with VSOS or CMS). > As for X3J3 only standardizing "existing practice", that's equivalent to > saying that only vendors should be allowed to do language design. One of I just hate the idea of committees doing design work. I would like to think that the vendors have a small number of folks doing design work, most of the team being programmers who implement the design. There are also researchers at universities doing design work. (Also hopefully not by committee.) > Carl Burch > HP Fortran Team -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.
cdb@hpclcdb.HP.COM (Carl Burch) (03/12/88)
I'm sorry, I could have been a great deal clearer. My point is that the "dependency" on previously compiled MODULEs is the same as that of INCLUDE files with the addition of one more check - that the source code of the module has not been modified since the module was compiled. In the implementations of modules with which I am familar (HP Modcal, Turbo Pascal Release 4.0), the compiled form of the module resides in a separate file from the source, so the regular file system modification dates provide the information to ensure that the compiled form is not out of date relative to the source code of the MODULE. With that one additional check, the dependencies introduced by USE are exactly those of INCLUDE. As for vendors doing the language design, let me refer you to what HP calls the "next bench" syndrome - the best way to design a tool (instrument, compiler, etc.) is to use it yourself and provide it to the guy at the next bench over in the lab. This works fine - but how many Fortran compilers do you know that self-compile? Not many any more, that has all but went out of style. There are other reasons to doubt that language design should be left to vendors, but they delve into the realm of Marketing - which I have sworn off (with other sins) for Lent. I hope that helps to clarify my previous response. Carl Burch HP Fortran
chris@metavax.UUCP (Chris Collins ) (03/12/88)
In article <1167@ut-emx.UUCP> reeder@ut-emx.UUCP (William P. Reeder) writes: >In article <6690013@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes: >> As for X3J3 only standardizing "existing practice", that's equivalent to >> saying that only vendors should be allowed to do language design. One of >I just hate the idea of committees doing design work. I would like to >think that the vendors have a small number of folks doing design work, >most of the team being programmers who implement the design. There >are also researchers at universities doing design work. I have to agree with Mr. Reeder here, in that standardizing committee's should not do language design. The reasoning is that the committee, I would guess, does not go home, implement the language change, and then use it for a while to see if it is really a good idea. Secondly, it also means that changes are, again, hopefully, out a real need from a user, instead of any other reason (it looks good; it might help it compete with other languages; etc.) ------ /MM/\MM\ META SYSTEMS, LTD. /MM/ \MM\ 315 E. Eisenhower /MM/ /\ \MM\ Suite 200 === == === Ann Arbor, MI 48108 \SS\ \/ /SS/ \SS\ /SS/ Chris Collins, Senior Programmer \SS\/SS/ ------ My colleagues chastised me for not saying these aren't my company's opinions. Companies don't have opinions.
jlg@a.UUCP (Jim Giles) (03/12/88)
In article <1167@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes: > I just hate the idea of committees doing design work. I would like to > think that the vendors have a small number of folks doing design work, > most of the team being programmers who implement the design. There > are also researchers at universities doing design work. (Also > hopefully not by committee.) I don't like the idea of letting the implementors do the design either. The people who write compilers often have never written a scientific program (I know some who have never SEEN a REAL production code). How can you expect these people to design useful extensions to a language when they have no concept of its use? A committee is the only workable way to design language extensions. Both users and implementors are required in order to develope features that are both useful to the users and possible to implement. (Of course, the size of the committee and its composition might be improved.) J. Giles Los Alamos
eugene@pioneer.arpa (Eugene N. Miya) (03/14/88)
In article <514@a.UUCP> jlg@a.UUCP (Jim Giles) writes: >In article <1167@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes: >> I just hate the idea of committees doing design work. >> . . . >> are also researchers at universities doing design work. > >I don't like the idea of letting the implementors do the design either. >The people who write compilers often have never written a scientific >program (I know some who have never SEEN a REAL production code). How >can you expect these people to design useful extensions to a language >when they have no concept of its use? > >A committee is the only workable way to design language extensions. Committees don't design languages. Typically one or two people design a language, the rest can only nod in agreement. Design is a real art. Basically, we really don't know how to design languages to satisfy every one: look at the diversity: APL, LISP, FORTRAN, ICON, Ada, etc. In the end, it really is the compiler writer (implementor) who has the greatest influence. The problem with these language standards committees is that they are dominated by special interest groups (largely manufacturers). If users expect a say, they HAVE to have representation. We currently have modification without representation. The problem is "minority" recourse. "Look we are going to change the language.." "Why nothing wrong with it to me..." So gee Jim, which of the user production codes do we look at? Suppose we look at one application, and it results in things not to "your" liking? The note from the fellow saying he didn't need structures, but wanted a complex type is a good example of whom we must carefully not listen. He represents a well-intended, but not well informed "electorate." He probably uses 2-D Complex arrays to implement quaterions. He wants Units? He should look at Verifible Pascal or other "experimental languages." But then, maybe, we should freeze languages for all time. Maybe as each new architecture comes out, we design a new language, then maybe some old applications, languages, and machines will die out... Nah.... From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
bobal@microsoft.UUCP (Bob Allison) (03/15/88)
In article <3038@metavax.UUCP> chris@metavax.UUCP (Chris Collins ) writes: >I have to agree with Mr. Reeder here, in that standardizing committee's >should not do language design. The reasoning is that the committee, >I would guess, does not go home, implement the language change, and >then use it for a while to see if it is really a good idea. >Secondly, it also means that changes are, again, hopefully, out a real >need from a user, instead of any other reason (it looks good; it might >help it compete with other languages; etc.) > And J. Giles of Los Alamos writes: >I don't like the idea of letting the implementors do the design either. >The people who write compilers often have never written a scientific >program (I know some who have never SEEN a REAL production code). How >can you expect these people to design useful extensions to a language >when they have no concept of its use? > >A committee is the only workable way to design language extensions. >Both users and implementors are required in order to develope features >that are both useful to the users and possible to implement. (Of course, >the size of the committee and its composition might be improved.) This is a basic dichotomy which is one of the reasons why the committee is having such trouble. I tend to agree with the first view, because I have an overriding faith in the marketplace over forty people's view of what is right and what is wrong with a language. Also, I know for a fact that the committee is having trouble defining certain features in the language because there is no existing implementation out there from which to get good experience and that worries me: what happens when we discover some really big problem with the precision stuff (and we are finding new problems at every meeting)? Once it is a standard, I for one am going to be pretty embarrassed when we discover some really big problem with one of these new features. Bob Allison Microsoft Member (kicking and screaming all the way) of X3J3 My opinions only. Your mileage may vary in actual road conditions.
bill@hcx2.SSD.HARRIS.COM (03/18/88)
> I'm sorry, I could have been a great deal clearer. My point is that the > "dependency" on previously compiled MODULEs is the same as that of > INCLUDE files with the addition of one more check - that the source code > of the module has not been modified since the module was compiled. In > the implementations of modules with which I am familar (HP Modcal, Turbo > Pascal Release 4.0), the compiled form of the module resides in a separate > file from the source, so the regular file system modification dates provide > the information to ensure that the compiled form is not out of date relative > to the source code of the MODULE. With that one additional check, the > dependencies introduced by USE are exactly those of INCLUDE. I agree, Carl, that the "dependency" is the same, but I believe there is danger here in that the compilation system is now leading the user on into a false sense of security. The tendency (particularly with Ada now becoming popular) will be for users to believe that now that the compiler _can_ check the dependency, it will. WRONG!!! First, there is no requirement in the standard that it do any such checking. Second, your proposed method for checking the dependency leaves out a very important safety check: How do you know that two independently-compiled routines that USE the same MODULE were compiled with the same version? This cannot be checked until link-time, because that is the first you have any clue that these two routines are part of one program. That is a much higher burden on the compilation system than simply checking a revision date of a file at compile-time. I don't assert that INCLUDE is any safer, better, or more powerful than MODULE. I only assert that it is such a widespread extension to FORTRAN that it should be standardized in 8x. As for MODULE, I think it is dangerous in its present form (because no checks are required), and I think that requiring the checks would impose too much burden on a compiler for a language that is supposed to compile fast and run fast. Given those opposing requirements, I think MODULE should be deleted. Bill Leonard Member, X3J3 Harris Computer Systems Division Fort Lauderdale, FL bill@ssd.harris.com
ssd@sugar.UUCP (Scott Denham) (03/26/88)
In article <1167@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes: > > I just hate the idea of committees doing design work. I would like to > think that the vendors have a small number of folks doing design work, > most of the team being programmers who implement the design. There > are also researchers at universities doing design work. (Also > hopefully not by committee.) > > -- > William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu Ah, but who ARE these coimmittees?? X3J3 is not a closed body; anyone can get on (or could have early on, anyway) that has the time and inclination to get involved. As we have vocally heard here and elsewhere, these vendors DO have reps on the committee, who presumably represent the ideas and opinions of the design folks you mention. Ditto for the universities, government research labs, etc. I'd like to see the standards process be a little more foresighted that merely "standardizing existing practice", because to me, that translates "change your existing code" to get to a "standard" language form. Clearly this can be overdone, though, and I think that's what's happened to 8x. Had 8x been less ambitious in it's goals, we might have had an 8x IN 198x, and got a 9x that might be very close to what's in 8x now (but will probably end up a 199x standard at the rate we are closing). In short, it's just too big a jump - but it's done, and other than the more awkward transition period, the end results will not be too much different than if it had been done more is steps. My big problem with the idea of taking 8x back to the table and making a 'new' language out of it is the problem of interlanguage linkage. Some vendors do better at this than others, but by making this a new language, all the issues of making the "new" structures (array sections, derived data types, etc) co-exist wit h the "old" language are dodged, and most vendors (mine at least) are not going to bend over backwards to see that you can mix the two. Thus to begin writing mains in the "new" language, I am forced to go back and convert many of my 2500+ library routines to the "new" language. Then I have dual maintenence to worry about, as I'm not likely to soon convert ALL of my mains to the 'new' language, surely not just to get a 2 line fix or upgrade in. I realize nothing in making 8x a "new" language forces the above scenario to occur, but its a lot more likely than in a single language/single product environment. Scott Denham Western Atlas International Who ME??? I didn't say that!!