Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 14 Mar 89 15:46:00 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 16:37 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > The proposal says:
    > Except where some other behavior is explicitly stated, when
    > the compiletime and runtime definitions are different, it is
    > unspecified which will prevail within the compiled code.
    >
    > This means that either the compiletime or the runtime definition
    > will prevail, but nothing else can happen.  It must also be
    > permissible to signal an error complaining about the discrepancy.

    The very first version of this proposal said "it is an error" here,
    back before we had started talking seriously about adopting new error
    terminology.  There was some discussion about it after that, the
    consensus of which seemed to be that the right behavior should really
    be "one or the other".  

    I personally don't see anything wrong with allowing (but not
    requiring) an error to be signalled, now that we seem to have agreed
    that isn't inconsistent with the term "unspecified".

with the term "the consequences are unspecified."

Then let's amend the proposal to permit signalling an error.  As it
currently reads, it does not permit that.  Or if you prefer, amend
the proposal to say

  Except where some other behavior is explicitly stated, when
  the compiletime and runtime definitions are different, the
  consequences are unspecified.