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 functions 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.


Clarifications and Logical Consequences:

The addition shall 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 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:

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


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:

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


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 with CASE.


Notes:

Implementations are encouraged to add the TEST keyword argument
to CL:CASE.

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


Revision history:

Version 1: posted (in text format) to the cdr-discuss list in July 2008.