[cdr-discuss] Issue CASE-TEST

[Nikodemus Siivola]

On Sun, Jul 6, 2008 at 12:13 PM, Leslie P. Polzer <leslie.polzer at 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