"Leslie P. Polzer" writes:

Finally wrote something up.

Please rip it apart where necessary.

The proposal doesn't say anything how the argument to the :test keyword is dealt with. Judging from the examples, the argument is supposed to be evaluated. I think your effort is misdirected. Why bother obfuscating CL:CASE? Make it a new operator. For example, in (*) I suggested to name such an operator SWITCH, and also proposed another operator called SELECT which behaves similiarly, but also evaluates each clause keys. I think providing the necessary changes to the Alexandria project would be more fruitful. Even more kudos if you grab some existing implementation, and actually come up with an efficient implementation of SWITCH. (In case of SBCL, I think there's actually prior work by Paul Khuong you could take leverage off.) -T. (*) http://common-lisp.net/pipermail/alexandria-devel/2008-June/000194.html

On Sun, Jul 6, 2008 at 12:13 PM, Leslie P. Polzer <leslie.polzer@gmx.net> wrote:

Please rip it apart where necessary.

I second Tobias' comments -- I think this is a misguided effort. That said, actual comments on the text:

Current practice:

Implementations may or may not define a TEST keyword argument for CASE, and they may follow arbitrary syntax protocols if they do.

Untrue. CLHS doesn't allow extending CASE (&co), invalid syntax in safe code must signal a PROGRAM-ERROR (or if you can find license to extend CASE like this from CLHS, the CDR should definitely reference the relevant points.) The only sense in which CLHS allows extending CASE is that of "1.5.1.5": "If the implementation conforms with some but not all of the requirements of this standard, then the conformance statement shall be ``<<Implementation>> conforms with the requirements of ANSI <<standard number>> with the following exceptions: <<reference to or complete list of the requirements of the standard with which the implementation does not conform>>.''" There are operators for which extensions by implementations make sense, since they are hard or effectively impossible to replace with user-provided ones -- eg. COMPILE-FILE and OPEN -- but for which extensions are not explicitly allowed. Non-conformance can be an acceptable price there.

Cost to Users:

None. This is an upwardly compatible change.

Untrue. You should not consider this a *change* to the standard, but a document describing on optional extension. What is the cost to users if *some* implementations implement this, and others do not? Answer: Descreased Portability in parts of code that are in no way essentially unportable (FFI, filesystem, operating system, compiler internals, etc.)

Cost of non-adoption:

Programs using the TEST keyword argument of CASE as proposed here will not run on implementations without support for it.

This is not a cost: you could equally well say that "As long as COMPILE-FILE does not accept :LANGUAGE keyword, people will be forced to use gcc, javac, and other compilers for other languages." Absence of a feature from the language is not a cost unless if causes problems. If several implementations implemented this keyword thing slightly differently, then there would be a cost. As they don't, the correct answer is "None".

Aesthetics:

Instead of relying on home-grown (and probably inefficient) macros or COND users will be able to state their intent clearly with CASE.

I strongly disagree. How about: "Instead of using portable standard constructs or libraries when needing behaviour described by this document, users are encouraged to employ a non-portable variation of a standard construct, with a syntax that resembles no other Common Lisp operator." In a word: "Questionable." In case you remain intent on this ...you're missing :KEY and :TEST-NOT. Possibly also :COUNT and :FROM-END. :) Cheers, -- Nikodemus