Copy in some Cliki issues

These are unformatted so that the git history will include what
they looked like before I edit them.

wscl-issues/proposed/array-upgrading-undecidable

@@ -0,0 +1,51 @@
+Issue: ARRAY-UPGRADING-UNDECIDABLE
+
+Forum: Editorial
+
+References: UPGRADED-ARRAY-ELEMENT-TYPE, MAKE-ARRAY
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2005-08-04, Version 1 by Paul F. Dietz
+
+Status: For CLiki consideration
+
+Problem Description:
+
+    UPGRADED-ARRAY-ELEMENT-TYPE and the definition of 'subtype' in the glossary imply that UPGRADED-ARRAY-ELEMENT-TYPE must be computable on all types, and that it can be used to distinguish between SATISFIES types that are type-equivalent to BIT and CHARACTER, respectively. This can easily be shown to be undecidable.
+
+Proposal (ARRAY-UPGRADING-UNDECIDABLE:RESTRICT):
+
+Modify the semantics of :(CLHS UPGRADED-ARRAY-ELEMENT-TYPE) so that its behavior on types for which SUBTYPEP is permitted to fail is unspecified. In particular, it is allowed to violate the subtype constraints in section 15.1.2.1 if the type being upgraded contains or can be expanded to a type that contains OR, AND, NOT, compound FUNCTION types, or SATISFIES.
+
+Test case:
+
+Rationale:
+
+As currently specified, the function cannot be correctly implemented.
+
+Current practice:
+
+    Ignore the problem and do not implement properly on complex compound types.
+
+Cost to Implementors:
+
+    None.
+
+Cost to Users:
+
+    None.
+
+Cost of Non-Adoption:
+
+    Inconsistency between implementations and the standard.
+
+Benefits:
+
+    Eliminates an impossible requirement.
+
+Aesthetics:
+
+Discussion:
+
+It may be desirable to require UPGRADED-ARRAY-ELEMENT-TYPE to respect ordering constraints on two types T1 and T2 if (SUBTYPEP T1 T2) is true, even if T1 and T2 contain any of the compound type specifiers listed above.

wscl-issues/proposed/define-compiler-macro-decline

@@ -0,0 +1,42 @@
+Issue: DEFINE-COMPILER-MACRO-DECLINE
+
+Forum: Editorial
+
+References: DEFINE-COMPILER-MACRO
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2004-06-16, Version 1 by Christophe Rhodes
+
+Status: For CLiki consideration
+
+Problem Description:
+    The glossary entry for compiler macro function is inconsistent with the entries in the main body of the standard: the glossary states that returning nil from the compiler macro function indicates that the original form should not be expanded, whereas define-compiler-macro states that this is achieved by returning the original form (from the &whole argument).
+
+Proposal (DEFINE-COMPILER-MACRO-DECLINE:ORIGINAL-FORM-ONLY):
+    Specify that the glossary entry was in error, and that to decline expansion the original form should be returned from the compiler macro function. Specify that a return value of nil indicates that the form should be expanded by the compiler, if it expands the compiler macro at all, to nil.
+
+Test case:
+
+Rationale:
+    The glossary entry was clearly in error, and could potentially cause confusion.
+
+Current practice:
+    SBCL 0.8.11 (and earlier versions), CMUCL 18e and CLISP 2.33 behave as in proposal DEFINE-COMPILER-MACRO-DECLINE:ORIGINAL-FORM-ONLY.
+
+Cost to Implementors:
+    Minimal.
+
+Cost to Users:
+    None.
+
+Cost of Non-Adoption:
+    Continued confusion over the required semantics of a compiler macro function.
+
+Benefits:
+    Enhanced ability to write compiler macros portably.
+
+Aesthetics:
+    Returning the original form to decline is clearly superior to returning nil, as it avoids any possible confusion over nil as expansion.
+
+Discussion:

wscl-issues/proposed/prog2-return-value

@@ -0,0 +1,42 @@
+Issue: PROG2-RETURN-VALUE
+
+Forum: Editorial
+
+References: PROG2
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2004-06-16, Version 1 by Christophe Rhodes
+
+Status: For CLiki consideration
+
+Problem Description:
+    The Description section in the specification for prog2 states that it returns the primary value of the first form in the body. This is in contradiction with the Syntax description as well as with common sense.
+
+Proposal (PROG2-RETURN-VALUE:SECOND-FORM):
+    Alter the Description section for prog2 to specify that the return value is the primary value of the second form in the body.
+
+Test case:
+    (prog2 1 2)
+
+Rationale:
+    Bugfix.
+
+Current practice:
+    No known implementation is incompatible with proposal PROG2-RETURN-VALUE:SECOND-FORM.
+
+Cost to Implementors:
+    None.
+
+Cost to Users:
+    None.
+
+Cost of Non-Adoption:
+    Continued need to explain the infelicities of the specification editing process.
+
+Benefits:
+    Specification will match reality more closely.
+
+Aesthetics:
+
+Discussion:

wscl-issues/proposed/standardized-restart-names

@@ -0,0 +1,48 @@
+Issue: STANDARDIZED-RESTART-NAMES
+
+Forum: Editorial
+
+References: RESTART-BIND, RESTART-CASE, WITH-SIMPLE-RESTART
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2004-06-16, Version 1 by Christophe Rhodes
+
+Status: For CLiki consideration
+
+Problem Description:
+    In the restrictions on conforming programs, section 11.1.2.1.2, point 18, it is specified that except where specifically allowed, the consequences are undefined if any symbols in the Common Lisp package are bound as a restart name. However, no such permission is given anywhere, even for the standardized restart names; strictly, this means that the user is unable to participate in the protocols defined by those restarts portably, by binding those names where it makes semantic sense.
+
+Proposal (STANDARDIZED-RESTART-NAMES:ALLOW-BINDING):
+    Explicitly allow binding the standardized restart names (abort, continue, muffle-warning, store-value and use-value) as restarts names by conforming code.
+
+Test case:
+
+(defun read-eval-print-loop (level)
+   (with-simple-restart (abort "Exit command level ~D." level)
+     (loop
+       (with-simple-restart (abort "Return to command level ~D." level)
+         (let ((form (prog2 (fresh-line) (read) (fresh-line))))
+           (prin1 (eval form)))))))
+
+Rationale:
+    read-eval-print-loop, above, is an example from the ANSI standard; it was clearly intended that this should work.
+
+Current practice:
+    The author knows of no implementation which is incompatible with proposal STANDARDIZED-RESTART-NAMES:ALLOW-BINDING.
+
+Cost to Implementors:
+    Minimal.
+
+Cost to Users:
+    None.
+
+Cost of Non-Adoption:
+    Continued inability to participate in the protocols defined by the ANSI standard.
+
+Benefits:
+    Enhanced portability of code, and enhanced ability of disparate programs to cooperate in protocols.
+
+Aesthetics:
+
+Discussion:

wscl-issues/proposed/values-&allow-other-keys

@@ -0,0 +1,47 @@
+Issue: VALUES-&ALLOW-OTHER-KEYS
+
+Forum: Editorial
+
+References: VALUES
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2004-07-20, Version 1 by Bruno Haible
+
+Status: For CLiki consideration
+
+Problem Description:
+
+    (values &allow-other-keys) matches the syntax for the VALUES type specifier, but the description doesn't say what it means. Because the syntax does not allow &key, &allow-other-keys was probably a mistake.
+
+Proposal (VALUES-&ALLOW-OTHER-KEYS:DISALLOW):
+
+    Don't mention &ALLOW-OTHER-KEYS as being allowed in the VALUES type specifier.
+
+Test case:
+
+Rationale:
+
+Current practice:
+
+    CLISP supports &KEY and &ALLOW-OTHER-KEYS.
+
+Cost to Implementors:
+
+    None.
+
+Cost to Users:
+
+    None.
+
+Cost of Non-Adoption:
+
+    Unclear spec.
+
+Benefits:
+
+Aesthetics:
+
+Discussion:
+
+    Bruno Haible supports proposal DISALLOW.

wscl-issues/proposed/with-hash-table-iterator-binding-type

@@ -0,0 +1,37 @@
+Issue: WITH-HASH-TABLE-ITERATOR-BINDING-TYPE
+
+Forum: Editorial
+
+References: WITH-HASH-TABLE-ITERATOR
+
+Category: CLARIFICATION/CHANGE
+
+Edit history: 2004-07-20, Version 1 by Bruno Haible
+
+Status: For CLiki consideration
+
+Problem Description:
+
+    The Exceptional Situations for WITH-HASH-TABLE-ITERATOR claim it establishes a local function. Should be a local macro.
+
+Proposal (WITH-HASH-TABLE-ITERATOR-BINDING-TYPE:???):
+
+Test case:
+
+Rationale:
+
+Current practice:
+
+Cost to Implementors:
+
+Cost to Users:
+
+Cost of Non-Adoption:
+
+Benefits:
+
+Aesthetics:
+
+Discussion:
+
+    Bruno Haible says: I agree, should be local macro. But since macros cannot be called, it needs reformulation.