[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CASEQ and SELECTQ
- To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI
- Subject: CASEQ and SELECTQ
- From: Guy Steele <GLS at SU-AI>
- Date: Mon ,11 Jun 79 01:43:00 EDT
CC: GLS at SU-AI, RPG at SU-AI
I have long wished for a couple of extra features in CASEQ, and
having them now would sure make coding a lot easier for me.
I propose that CASEQ and SELECTQ mean slightly different things.
SELECTQ would remain as it is now, and CASEQ would mostly remain
the same, except for two added features:
 If there is no default (i.e., T or OTHERWISE) clause in a SELECTQ,
the default value () is produced. I suggest that a CASEQ instead
produce some sort of correctable error as the "default default".
This correctable error for (CASEQ <form> ... <no-T-clause-at-end>)
ideally would be something like
(FERROR ':UNSEEN-CASE-KEY ;or maybe UNSEEN-GO-TAG?
"The CASEQ key ~S produced by <form> does not occur in the CASEQ"
If the error is corrected, the CASEQ should be retried with the
This is a construct I am constantly reconstructing by hand. It wouldn't
be too hard to write a macro for CASEQ in terms of SELECTQ to do this.
 I wish there were a construct (CASEGO <form>), which would take an
evaluated argument and effectively jump to the top of the containing
CASEQ and perform the selection with the specified item. (I suppose
there would have to be a CASEQ-NAMED as well to handle a CASEGO to
an outer CASEQ. In that case (sorry), CASEGO should take an optional
unevaluated second argument, as for GO.)
In the situation where the first argument to CASEGO is a constant,
then the code can be optimized to go directly to the relevant clause.
I find that I am using CASEQ a lot, and either the processing for one
key involves doing a diddle and then doing code identical to that for
another key; or I want to do my own error handling and write
(T (WARN "you blew it, bunky; I'll assume BAR for now")
instead I have to resort to the awkward
(T (OR (EQ <form> 'BAR)
(WARN "you blew it, bunky; I'll assume BAR for now"))
which is asymmetrical in the keys, requires me to put the code for BAR
last, and requires me to write <form> twice.