[comp.lang.fortran] F8X: MODULE vs. INCLUDE

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!!