[alexandria-devel] Review cycle 2: SWITCH, ESCWITCH, and CSWITCH

[Gustavo]

2010/4/5 Pascal J. Bourguignon <pjb at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/alexandria-devel/attachments/20100406/29ae8e52/attachment.html>