Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)

[alarson@src.honeywell.com (Aaron Larson)]

>IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
>			situation in ANY ONE of the following ways: (1)
>			When the situation occurs, an error should be 
>			signalled at least in safe code, OR (2) When the 
>			situation occurs, the "consequences are undefined", 
>			OR (3) When the situation occurs, the consequences are

Item (1) should either be:

  When the situation occurs, an error "should be signalled",

Or simply deleted entirely since it is really a subset of (2)/(3)

>WARNING IS ISSUED	A warning is issued, as described in WARN, in
>			both safe and unsafe code when the situation
>			is detected. Conforming code may rely on the
>			fact that a warning will be issued in both
>			safe and unsafe code when the situation is
>			detected.  Every implementation is required to
>			detect this situation in both safe and unsafe
>			code when the situation is detected. The
>			presence of a warning will in no way alter the
>			value returned by the form which caused the
>			situation to occur. For example, "a warning is
>			issued if a declaration specifier is not one
>			of those defined in Chapter 9 of CLtL and has
>			not been declared in a DECLARATION
>			declaration."

"Every implementation is required to detect this situation in both safe and
unsafe code."  (i.e. delete the "when the situation is detected").

Also; "The presence of a warning will in no way alter the value
returned..." is a little strong.  I think some weasel words like "in the
absence of handlers for contitions of type warning, the presence of a
warning will ...".  Unless of course we intend to disallow users from
setting up handlers for warnings that throw out, which would of course
change the value returned since there wouldn't be any.