Issue CASE-TEST


References:

  * http://www.lisp.org/HyperSpec/Body/mac_casecm_ccasecm_ecase.html
  * http://common-lisp.net/pipermail/cdr-discuss/2008-March/000069.html
  * http://clisp.cons.org/impnotes/fcase.html
  * http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/5a4374e8e589e802/df2280da4647d84b


Related Issues: None.


Category: Addition.

Note: in this document, CASE refers to the macros CASE, CCASE, ECASE.
Note: in this document, KEYFORM refers to the KEYFORM argument of
CASE and ECASE and the KEYPLACE argument of CCASE alike.


Problem Description:

CASE always utilitizes the EQL predicate for its comparisons.


Proposal:

Add a :TEST keyword argument to the CASE macro, allowing arbitrary predicates
to be specified.

Alternatively, add another macro that supports this functionality.


Clarifications and Logical Consequences:

If implemented as an extension of CASE functionality,
the addition must not break the standard syntax of CASE.
It is therefore not permitted to pass the KEYFORM and the optional
TEST parameter inside a list. Instead, the macro should look
for a keyword following the KEYFORM and honor it, if present.

If implemented as a new macro

The value of the TEST keyword argument shall be evaluated.

If the TEST keyword argument is not present, CASE shall use
the EQL predicate.


Examples:

;; 1
(case "foo"
  ("foo" t))

=> NIL ; classical behaviour

;; 2
(case "foo" :test #'equal
  ("foo" t))

=> T

;; 3
(case "foo" :test #'equalp
  ("Foo" t))

=> T


Rationale:

With this additions, CASE can be used to compare, for example, sequences
in an element-wise fashion (like with EQUAL).


Current practice:

There is no TEST keyword argument for CASE.
There is no standard macro signature for the addition
proposed here.


Cost to implementors:

Depends on efficiency.

The cost to add support for arbitrary tests is negligible,
but implementing an efficient version for predicates other
than EQ or EQL requires some effort.


Cost to Users:

None.  This is an upwardly compatible change.


Cost of non-adoption:

None.


Performance impact:

None at runtime. Probably non-significant overhead at compile time.


Benefits:

More flexible usage of CASE.


Aesthetics:

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


Notes:

Implementations are encouraged to provide efficient versions
of this extended CASE for the EQUAL and EQUALP predicates.


Revision history:

Version 1: posted (in text format) to the cdr-discuss list in July 2008.
Version 2: (clarifications): the value to :TEST shall be evaluated.
Version 3: be less specific about the nature of the implementation.
           replace erronous "function" with "macro", since that's
           what CASE is.