🚀 go-pugleaf

From article <6555:Nov720:35:2690@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> In article <5093@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> From article <7456:Nov620:54:4090@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> [...]
>> > In which case the error will be detected at *compile time*, when the
>> > compiler gets around to that .c file. I stand by my statement.

I leave it up to the rest of the net.  Does the above statement sound
like separate compilation is allowed in Dan's model?  If so, it must
be clear to everyone that there may not _be_ a .c file corresponding
to the .h file - the code might be proprietary, the vendor sent the
.h file and the .o file and nothing else.  So, how does the compiler
check at compile time when it "gets around to that .c file" which
doesn't even exist?

> [...]
> Yes, and when code has bugs, you fix the code. You don't rewrite your
> compiler and loader to use some idiotic replacement for the concept of a
> package.

I will ignore the fact that you're being ad hominem again.  I don't
suggest an 'idiotic' replacement for packages.  In fact, I support
packages (or modules, or whatever you want to call them).

What I don't do is suggest that the compiler involve itself in an
elaborate scheme to avoid requiring the user to make a few simple
declarations about aliasing.  Even if your scheme works (it's long,
I'll have to study it), it enlarges .o files by factors which are
probably exponential in the number of procedure arguments; it
requires that many extra passes through the compiler for each
code (at least through the code generation phase of the compiler);
and it looks extremely cumbersome and unreliable.  And, it _does_
require modifications to the loader (at least to the extent of
recognising all the long suffixes to the procedure names which
describe which combination of aliasing is allowed in each object
code version).

J. Giles