Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.misc Subject: Re: Answers, Chapter 1: TeX Message-ID: <5224@lanl.gov> Date: 7 Nov 90 22:20:07 GMT References: <6555:Nov720:35:2690@kramden.acf.nyu.edu> Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 38 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