Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX
Message-ID: <7456:Nov620:54:4090@kramden.acf.nyu.edu>
Date: 6 Nov 90 20:54:40 GMT
References: <2047:Nov607:10:1690@kramden.acf.nyu.edu> <5077@lanl.gov>
Organization: IR
Lines: 23

In article <5077@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> From article <2047:Nov607:10:1690@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> > In article <4349@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> > [...]
> > The .h-.c (package spec-package body) model is sufficient to detect
> > procedure call interface errors at compile time.
> Not if the information in the .h file _doesn't_match_ the definition
> of the corresponding routines in the .c file.

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.

> The compiler must
> provide sufficient information to tell the loader which constraints
> must be promoted across the call-tree - but this information can
> exist in a language independent form.

I suppose you could have the loader accept arbitrary strings from the
compiler describing these constraints, but then it's not going to
generate intelligent error messages. Have you ever used AT&T's C++?
This isn't a very good solution. The compiler can do a much better job.

---Dan