Hello folks, here are three CDR ideas that I would like to get your comments on: 1. Support a :TEST arg for (E)CASE. 2. Setup BACKQUOTE to be the backquote expansion object. I believe this is common implementor's practice. 3. Support extended feature tests. It would be nice to be able to say +(find-package 'zoo)(...) The complexity impact is none for #2, probably neglectable for #3 and should be moderate for #1. Leslie
here are three CDR ideas that I would like to get your comments on:
1. Support a :TEST arg for (E)CASE.
It would be nice for case to have a :test argument and a :key argument too. The "tricky" part is where to put them, yes? (case <thing> (<case1> <form1>) ... (t <formn>)) doesn't leave much room for options. Are you thinking of something like (defmacro my-case ((it &key test key) &body clauses) ...) so that it would look like (my-case (thing :test 'foo) (<case1> <form1>) ... ) ??
2. Setup BACKQUOTE to be the backquote expansion object. I believe this is common implementor's practice.
3. Support extended feature tests. It would be nice to be able to say +(find-package 'zoo)(...)
The complexity impact is none for #2, probably neglectable for #3 and should be moderate for #1.
Leslie
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Dear Gary,
doesn't leave much room for options. Are you thinking of something like
(defmacro my-case ((it &key test key) &body clauses) ...)
so that it would look like
(my-case (thing :test 'foo) (<case1> <form1>) ... )
Yes, something like that. Of course, the best solution would consist of being able to say just (case thing :test #'equal (<case1> <form1>) (...)) but I believe the macro lamda list syntax won't let us. Leslie
On 18 Mar 2008, at 11:08, Leslie P. Polzer wrote:
Dear Gary,
doesn't leave much room for options. Are you thinking of something like
(defmacro my-case ((it &key test key) &body clauses) ...)
so that it would look like
(my-case (thing :test 'foo) (<case1> <form1>) ... )
Yes, something like that. Of course, the best solution would consist of being able to say just
(case thing :test #'equal (<case1> <form1>) (...))
but I believe the macro lamda list syntax won't let us.
That's not an issue: (defmacro case (thing &body body) ...) ...and do the parsing of body manually inside the macro. For example, defmethod and define-method-combination have to do that as well. In case of case (ha!), the parsing should be easy: What follows after thing is either :test or a cons, that's easy to distinguish. Pascal -- 1st European Lisp Symposium (ELS'08) http://prog.vub.ac.be/~pcostanza/els08/ Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
but I believe the macro lamda list syntax won't let us.
That's not an issue:
(defmacro case (thing &body body) ...)
...and do the parsing of body manually inside the macro. For example, defmethod and define-method-combination have to do that as well.
In case of case (ha!)
In English, puns mostly come for free. :)
, the parsing should be easy: What follows after thing is either :test or a cons, that's easy to distinguish.
Sounds good, thanks. I might write up a CDR for this, then. Leslie
On Tue, 18 Mar 2008 11:08:45 +0100 (CET), "Leslie P. Polzer" <leslie.polzer@gmx.net> wrote:
(my-case (thing :test 'foo) (<case1> <form1>) ... )
Yes, something like that. Of course, the best solution would consist of being able to say just
(case thing :test #'equal (<case1> <form1>) (...))
Why "of course"? If you think that brevity is the most important thing and parentheses have to be avoided at any cost, then maybe. Other than that, I think that (case (thing :test 'foo) (etc... is easier to understand and read. Edi.
On 18 Mar 2008, at 12:16, Edi Weitz wrote:
On Tue, 18 Mar 2008 11:08:45 +0100 (CET), "Leslie P. Polzer" <leslie.polzer@gmx.net
wrote:
(my-case (thing :test 'foo) (<case1> <form1>) ... )
Yes, something like that. Of course, the best solution would consist of being able to say just
(case thing :test #'equal (<case1> <form1>) (...))
Why "of course"? If you think that brevity is the most important thing and parentheses have to be avoided at any cost, then maybe. Other than that, I think that
(case (thing :test 'foo) (etc...
is easier to understand and read.
...but that's ambiguous: (defun thing (&key test) (declare (ignore test)) 42) (defvar thing 4711) (case (thing :test #'=) (42 'foo) (4711 'bar)) What's the result of that form? Pascal -- 1st European Lisp Symposium (ELS'08) http://prog.vub.ac.be/~pcostanza/els08/ Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Why "of course"? If you think that brevity is the most important thing and parentheses have to be avoided at any cost, then maybe. Other than that, I think that
(case (thing :test 'foo) (etc...
is easier to understand and read.
Probably a matter of taste and editing environment. My environment highlights keyword arguments in bright green, so I'm probably quite biased in my opinion that my proposal excels not only in brevity but also readability. But it also fits in with the rest of functions taking a TEST keyword argument, where (MEMBER obj list :TEST #'EQL) is just one example of... Leslie
On Tue, 18 Mar 2008 12:55:28 +0100 (CET), "Leslie P. Polzer" <leslie.polzer@gmx.net> wrote:
Probably a matter of taste and editing environment. My environment highlights keyword arguments in bright green, so I'm probably quite biased in my opinion that my proposal excels not only in brevity but also readability.
Yes, the font-lock settings of your particular IDE probably aren't a good deciding factor...
But it also fits in with the rest of functions taking a TEST keyword argument, where (MEMBER obj list :TEST #'EQL) is just one example of...
I wasn't arguing against the TEST keyword argument, I was talking about syntax. Note that the we are discussing is a macro and not a function. I fail to see how the question whether MEMBER accepts a TEXT keyword argument or not fits into this.
"Leslie P. Polzer" <leslie.polzer@gmx.net> writes:
2. Setup BACKQUOTE to be the backquote expansion object. I believe this is common implementor's practice.
I don't believe it is. (What is "the" backquote expansion object, anyway?)
3. Support extended feature tests. It would be nice to be able to say +(find-package 'zoo)(...)
#+#.(cl:if (cl:find-package 'zoo) '(and) '(or)) (...) Cheers, Christophe
Dear Christophe, you wrote:
(What is "the" backquote expansion object, anyway?)
I'm not sure what you are asking here. The object is what ` expands into, which is undefined by the spec (as is the expansion of , and ,@). CLISP shows this behaviour: [35]> (defmacro showexp (form) (format t "~{~A~}~%" form)) SHOWEXP [36]> (showexp `(zoo)) BACKQUOTE(ZOO) NIL [37]> (showexp `(,@zoo)) BACKQUOTE((SPLICE ZOO)) NIL [38]> (showexp `(,zoo)) BACKQUOTE((UNQUOTE ZOO)) NIL Whereas SBCL seems to have some things going on under the hood: CL-USER(3): (showexp `(,@zoo)) debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" {A723549}>: The value ZOO is not of type LIST. CL-USER(7): (showexp `(,@(list 1 2))) BACKQ-LIST/1/2/ NIL A CDR would fix certain parts of this behaviour. Leslie
"Leslie P. Polzer" <leslie.polzer@gmx.net> writes:
Dear Christophe,
you wrote:
(What is "the" backquote expansion object, anyway?)
I'm not sure what you are asking here. The object is what ` expands into, which is undefined by the spec (as is the expansion of , and ,@).
But according to the current spec, ` need not expand into anything at all. What I am challenging is your assertion that there should be a single ("the") backquote object that ` always expands to.
Whereas SBCL seems to have some things going on under the hood:
Yes, it does: it performs read-time optimizations, as it is allowed to. If you want to disallow those read-time optimizations, that's fine, but you then have to make a case for that (rather than simply begging the question by assuming that they are never performed). Cheers, Christophe
But according to the current spec, ` need not expand into anything at all. What I am challenging is your assertion that there should be a single ("the") backquote object that ` always expands to.
It would be handy and add consistency (why is the expansion for quote defined but not the one for backquote?).
Whereas SBCL seems to have some things going on under the hood:
Yes, it does: it performs read-time optimizations, as it is allowed to. If you want to disallow those read-time optimizations, that's fine, but you then have to make a case for that (rather than simply begging the question by assuming that they are never performed).
I didn't mean to beg the question, I intend to have a honest conversation. It's just that I didn't know of these optimizations. Do you have any idea of the performance impact here? Leslie
On 18 Mar 2008, at 12:09, Leslie P. Polzer wrote:
But according to the current spec, ` need not expand into anything at all. What I am challenging is your assertion that there should be a single ("the") backquote object that ` always expands to.
It would be handy and add consistency (why is the expansion for quote defined but not the one for backquote?).
It is also sometimes the case that you want to expand into a use of backquote, unquote and unquote-splicing in your own macro definitions. In some cases, this can be very handy. But in Common Lisp, these things are handled at readtime, that's too early for macroexpansion. I could imagine a compromise where backquote, unquote and unquote- splicing is available as special forms, but where the corresponding syntax is not required to expand into those. Although I don't know what the implications thereof are... Pascal -- 1st European Lisp Symposium (ELS'08) http://prog.vub.ac.be/~pcostanza/els08/ Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
On 16 Mar 2008, at 14:57, Leslie P. Polzer wrote:
Hello folks,
here are three CDR ideas that I would like to get your comments on:
1. Support a :TEST arg for (E)CASE.
I'm not sure what this buys you over a regular cond. Case primarily exists for efficiency, no?
2. Setup BACKQUOTE to be the backquote expansion object. I believe this is common implementor's practice.
It would indeed be good if it were standardized what the ` , and ,@ expand into. However, this should take into account current practice, so would need an analysis stage first, I think. This sounds like hard work (but maybe I'm overestimating this). Whether it's common already or not doesn't matter that much. Those implementations that don't want to implement the CDR don't implement the CDR.
3. Support extended feature tests. It would be nice to be able to say +(find-package 'zoo)(...)
I don't think that's a good idea because it changes the semantics of boolean expressions. (when :some-keyword (print 'foo)) will always print 'foo, whereas #+some-keyword (print 'foo) prints 'foo only if :some-keyword is on the feature list. In other words, this may lead to some unexpected results. What's wrong with this? #.(if (find-package 'zoo) '(do-this ...) '(do-that ...)) Pascal -- 1st European Lisp Symposium (ELS'08) http://prog.vub.ac.be/~pcostanza/els08/ Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
1. Support a :TEST arg for (E)CASE.
I'm not sure what this buys you over a regular cond. Case primarily exists for efficiency, no?
Hi Pascal, I see your point _but_ there is also something to be said for efficiency of human code reading and code writing, no? I'd say that case variants let the reader know that all of the tests are of the form "this" is the same as "that" for some notion of "same as" and various "that"s. (case <this> (that-1 ...) (that-2 ...) ...) whereas cond is saying, do an arbitrary test for each possible branch... This may not be enough to argue for adding to / extending case... cent, cent, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Gary King wrote
Pascal Constanza wrote:
1. Support a :TEST arg for (E)CASE.
I'm not sure what this buys you over a regular cond. Case primarily exists for efficiency, no?
Hi Pascal, I see your point _but_ there is also something to be said for efficiency of human code reading and code writing, no? I'd say that case variants let the reader know that all of the tests are of the form "this" is the same as "that" for some notion of "same as" and various "that"s.
(case <this> (that-1 ...) (that-2 ...) ...)
whereas cond is saying, do an arbitrary test for each possible branch...
This may not be enough to argue for adding to / extending case...
I have mixed feelings about this. On one hand, it is a handy idiom. On the other hand, CASE (and ECASE and maybe, to some extent TYPECASE) are by now well-ingrained as efficient idioms. I would personally be happier if there was an "almost CASE" with user- controllable test, whose name didn't actually contain "CASE" at all. Unfortunately, I don't think SWITCH is a good name, either. I notice that I can't see a SELECT in the HyperSpec, maybe that would be a neutral-enough name for this sort of construct? Something along the lines of: (select (form &optional (test #'eql)) ...) With the forms following being similar to the ones used in CASE/ECASE? It is a handy idiom, in that respect and I have whipped up some in the past (though, I must admit, special-purpose ones, each time, rather than a general one). //Ingvar
Hello Pascal, thanks for your comments.
1. Support a :TEST arg for (E)CASE.
I'm not sure what this buys you over a regular cond. Case primarily exists for efficiency, no?
Clarity of semantics. As Gary already pointed out somewhat, COND models “branch according to arbitrary predicates”, while CASE models “branch according to equality of a variable binding”. But an extended CASE would also, by way of this semantical difference, extend the efficiency by letting the compiler optimize it (e.g. via hash tables). This is hardly possible with a COND).
It would indeed be good if it were standardized what the ` , and ,@ expand into. However, this should take into account current practice, so would need an analysis stage first, I think. This sounds like hard work (but maybe I'm overestimating this).
Why do you think so?
3. Support extended feature tests. It would be nice to be able to say +(find-package 'zoo)(...)
I don't think that's a good idea because it changes the semantics of boolean expressions. (when :some-keyword (print 'foo)) will always print 'foo, whereas #+some-keyword (print 'foo) prints 'foo only if :some-keyword is on the feature list. In other words, this may lead to some unexpected results.
Yeah, let's scrap #3. Leslie
On 18 Mar 2008, at 10:46, Leslie P. Polzer wrote:
Hello Pascal,
thanks for your comments.
1. Support a :TEST arg for (E)CASE.
I'm not sure what this buys you over a regular cond. Case primarily exists for efficiency, no?
Clarity of semantics. As Gary already pointed out somewhat, COND models “branch according to arbitrary predicates”, while CASE models “branch according to equality of a variable binding”.
But an extended CASE would also, by way of this semantical difference, extend the efficiency by letting the compiler optimize it (e.g. via hash tables). This is hardly possible with a COND).
Well, I think it is, but I see your point better now.
It would indeed be good if it were standardized what the ` , and ,@ expand into. However, this should take into account current practice, so would need an analysis stage first, I think. This sounds like hard work (but maybe I'm overestimating this).
Why do you think so?
...because I recall reading that the semantics of backquote is not so straightforward, and my experience with other constructs in Common Lisp (and other languages for that matter) shows that the devil is in the details. Pascal -- 1st European Lisp Symposium (ELS'08) http://prog.vub.ac.be/~pcostanza/els08/ Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
participants (7)
-
Attila Lendvai -
Christophe Rhodes -
Edi Weitz -
Gary King -
Ingvar -
Leslie P. Polzer -
Pascal Costanza