Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!rex!ukma!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 status
Message-ID: <23069@lanl.gov>
Date: 2 May 91 14:41:36 GMT
References: <1991Apr24.202115.16119@dragon.wpd.sgi.com> <22900@lanl.gov> <5526@goanna.cs.rmit.oz.au>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 26

In article <5526@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
|> In article <22900@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
|> > [... type checking arguments to procedures ...]
|> 
|> [...]                    The Burroughs B6700 Fortran compiler did just
|> such a check, and always did so even before there _was_ a B6700.  What's
|> more, the compiler _did_ check calls to routines that were in the same
|> source file.  No, this did _not_ make anything incompatible with the
|> possibility of separate compilation. [...]

The type check itself could easily be made obsolete by later recompiling
just one of the procedures that was formerly in the same source file.
Separate compilation in Fortran makes no mention of 'files' at all.
So, depending on information from within the same source file is not
sufficient to be _sure_ of type match.

|> [...]                              Burroughs object files contained
|> full symbol tables.  (UNIX object files may do so too.  I have never
|> understood why UNIX compilers didn't exploit this.)

This is why it's easy to do this in the loader.  The information is
usually there (in the symbol tables).  Further, the information is
in its final form: all the compilation is done by the time the loader
runs.

J. Giles