conformance & extensions issues

[masinter.pa@Xerox.COM]

These was in discussion on the common lisp mailing list, but it is relevant
to the conformance discussion, and probably should be split up into
separate issues. I've not the time to do so myself. There's some overlap
with a couple of cleanup issues but not much. I think these are not so much
"cleanup" issues since they have to deal with the broad policies of
conformance and extension rather than individual functions/variables, so
I'd think they should be discussed in the "editorial" forum rather than
cleanup -- unless there is strong objection.


Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Problem:

Is it OK to define Common Lisp functions with extra optional or  keyword
parameters, with system dependent meanings?  

Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED

No, except as explicitly allowed in the standard. Functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list. Functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS. 

It isn't required that implementations signal errors at all safety/speed
setting, but this is not legitimate/conformal behavior.

Rationale:
The goal is not to outlaw any current extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard.  Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.

Issue: EXTRA-SYNTAX
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?

Proposal:  EXTRA-SYNTAX:NO

It isn't allowed.

Issue: EXTRA-RETURN-VALUES
Problem: Is it OK to return extra values from Common Lisp functions?

Proposal: No, except where explicitly allowed. The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."

Issue: UNPSECIFIED-DATATYPES
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL?  

Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED

Example: It is currently not allowed for an implementation to define + as
operating on vectors.
 
Rationale: While the original intent of CL designers ws that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function 
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.


Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?

Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)

Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.


Issue: MACRO-AS-FUNCTION
Problem: May implementations implement things documented as "macros" or
special forms be implemented as a function instead? PROG1 is the main
example, but there might be others.

Proposal: MACRO-AS-FUNCTION:YES

Things that are defined in CL as "macros" may have function definitions
instead if the semantics can be preserved. This is rare, perhaps only
restricted to

(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)

Rationale: 
There are few cases, and there doesn't seem to be a good reason to disallow
it. It doesn't seem to interfere with portability.