Re: Crosspost: Help wanted from comp.compilers

["John R. Strohm" <strohm@airmail.net>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058390613.119827@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > Consider a package spec, that declares a procedure.  Change the
procedure
>
> Did you actually read what I and some of the sites I quoted said?
>
> The broken systems triggered cascading recompiles when a spec was
> recompiled *whether or not the spec had changed*. There are several
> instances mentioned where people wanted to recompile a module for
> extra debugging or optimization, and that in itself triggered the
> cascade, even though no source file had changed.

Hyman, it occasionally appears to me that you insist on thinking with your
preconceptions rather than your brain.

Consider a C example, first.

magic_value.h:
#ifndef _MAGIC_VALUE
#define _MAGIC_VALUE
#define MAGIC 42
#endif

test_array.c:

#include "magic_value.h"
static int bletch[4] = { MAGIC, MAGIC, 0, MAGIC };
void main(void)
{
  /* do something with bletch[] */
}

Now, Hyman, it should be immediately obvious, even to you, that, if we
change the line that defines the magic value in the .h file, we HAVE to
recompile the .c file as well, even though the .c file has not changed one
iota.

Let's go a step further.

magic_value.h:
#ifndef _MAGIC_VALUE
#define _MAGIC_VALUE
#define MAGIC 42
#endif

magic_square.h:
#ifndef _MAGIC_SQUARE
#define _MAGIC_SQUARE
#include "magic_value.h"
#define MAGICSQUARE ((MAGIC)*(MAGIC))
#endif

test_square.c:
#include "magic_square.h"
static int magic_square[MAGICSQUARE];
void main(void)
{
  for (i=0;i<MAGICSQUARE;i++){
    magic_square[MAGICSQUARE] = i;
  }
}

In this example, Hyman, by your argument, we should be able to change MAGIC
in magic_value.h and NOT have to recompile test_square.c, because the source
code for magic_square.h has not changed.

However, the MEANING, the SEMANTICS, of magic_square.h HAVE changed, because
the semantics UNDERLYING magic_square.h, i.e., the magic value MAGIC, have
changed.

The same thing can occur in Ada.  An overt change in one specification may
propagate through a chain of apparently-unchanged descendants, producing
hidden but very real semantic changes in each of them, and eventually
producing a very visible change in the final descendant.