[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
- To: Sandra J Loosemore <firstname.lastname@example.org>
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 16 Mar 89 14:17 EST
- Cc: email@example.com
- In-reply-to: <8903142246.AA03773@defun.utah.edu>
Date: Tue, 14 Mar 89 15:46:00 MST
From: firstname.lastname@example.org (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.