2010/4/5 Pascal J. Bourguignon pjb@informatimago.com
[...]
I don't like adding such "syntax" when a pair of parentheses would just do, or even better, if we can come out with a regular syntax that doesn't need special treatments.
Ok, it would be ok by me if I have to use one more parenthesis to evaluate forms. If others prefer more parenthesis than more keywords, more parenthesis it is.
Regarding to not have special treatments, I think this only benefits the macro implementation, not the users, so I vote for having special treatments.
[...]
If we choose run-time evaluation, there is the question of the order of evaluation. Of course, the keys would be evaluated in sequence to stay with CL evaluation principles. But do we want short-cut evaluation, or can we imagine an algorithm where evaluating all the keys at once, and then finding the branch would be more efficient? (eg. if we could evaluate and select in parallel). In which case we would also have to deal with duplicate values for the keys, possibly in different branches. Currently, I don't see that we could provide anything better than testing sequentially, and therefore, short-cut evaluating the keys would be expected. (This is the current COND-like behavior).
I believe that run-time evaluation sequentially and short-cutting whenever the key matches some value. About evaluating and selecting keys in parallel, you mean using multiple threads? Unless the evaluation of the keys take a really long time, that would only slow down the process. If the evaluation takes a long time, the user could use multiple threads if he or she finds pertinent.
Given a sensible default for :test, I find it unexpected to expect to surround the expression in parentheses. Since all the clauses are lists, I would propose to leave the keyword options at the same level:
(<switch-operator> <expression> [ :test <test-expression> ] <clauses>)
The problem is it would be bad for automatic indentation.
A alternative would to use the model given in the link provided by Nikodemus: http://common-lisp.net/project/bknr/static/lmman/fd-flo.xml#select
but, instead of *select* and *selector*, I vote for *switch*** and *switch** :
(switch <expression> <clauses>)
(switch* <expression> <test-expression> <clauses>)
[...]
Finally, concerning the list of keys per clauses, by the same reasoning as for :key, and given the choice fo run-time evaluation of the clause keys, I'd tend to think that we can restrict ourselves to a single value. If the user wants to check against a list of keys, she can do it with a specific :test funtion:
(switch item :test (function member) ('(1 2 3) ...) ((list (get-one) (get-another)) ...) ((list *a-single-one*) ...) (otherwise ...))
To be honest, if I had to write such a test, I would rather find another way to do what I want (e.g. using cond). This looks ugly.
Also, given run-time evaluation, I'd accept only OTHERWISE for the default clause, and leave T as a normal constant symbol to be evaluated and tested against, because T is a common value in lisp programs, while OTHERWISE is not.
This would make *switch* inconsistent with *case*, but I will not object if T is treated as a normal constant symbol.
At first I wouldn't make it an error to include an OTHERWISE clause in ESWITCH or CSWITCH, just a warning. For me, ESWITCH means "I cover all the cases", and if I use OTHERWISE to do so, good for me! On the other hand, I would understand the choice of making it an error. In this case, please add a mention to use SWITCH instead of ESWITCH/CSWITCH in the error message.
I have no objections here.
I put 'function designator', but it could be 'funcallable'. I don't know if funcallable CLOS objects are designators of functions. But my point is that the function forms are evaluated. I would reject: (switch x :test string= ...).
I also vote for the test function to be evaluated. In my opinion, anything funcallable should be usable, unless someone finds a specific reason why it shouldn't be so.
SCASE could be written:
(switch <string-expression> :test (function string=) ("abc" ...) ("def" ...) ... (otherwise ...))
Note that when all the strings and the test function are literals (known at compilation-time), special run-time optimizations may apply.
-- __Pascal Bourguignon__ http://www.informatimago.com