[pro] #; comments...
Hi, I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well. Here is a suggested wording. ------------- snip ----------------- #; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place. #; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read. ------------- snip ----------------- The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document. Any comments or ideas about this? Best, Pascal -- Pascal Costanza
+1 On May 6, 2012, at 20:57 , Pascal Costanza wrote:
Hi,
I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
Here is a suggested wording.
------------- snip -----------------
#; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place.
#; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.
------------- snip -----------------
The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document.
Any comments or ideas about this?
Best, Pascal
-- Pascal Costanza
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
Hello, You say #+nil is not reliable, which I agree with. However, what I'm in the habit of using is #+#:ignore, which AFAIK should be always reliable: #:ignore won't and can't be interned. Even if #:ignore is in your features, it won't help. CL-USER> (push '#:ignore *features*) (#:IGNORE ...) CL-USER> (+ 1 #+#:ignore 2 3) 4 I do use this in practice, and I also use it as a form of documentation on why I'm commenting something out. As a sort of contrived example: (defun f () #+#:ignore-buggy (progn ...) ; buggy code (progn ...)) ; working code Though, this is certainly clunkier than a dedicated #; macro. Cheers! Robert Smith quad@symbo1ics.com On Sun, May 6, 2012 at 1:57 PM, Pascal Costanza <pc@p-cos.net> wrote:
Hi,
I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
Here is a suggested wording.
------------- snip -----------------
#; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place.
#; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.
------------- snip -----------------
The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document.
Any comments or ideas about this?
Best, Pascal
-- Pascal Costanza
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
Hi, I haven't thought of that idea. But it does look ugly, doesn't it? ;) Pascal On 6 May 2012, at 21:07, Robert Smith wrote:
Hello,
You say #+nil is not reliable, which I agree with. However, what I'm in the habit of using is #+#:ignore, which AFAIK should be always reliable: #:ignore won't and can't be interned.
Even if #:ignore is in your features, it won't help.
CL-USER> (push '#:ignore *features*) (#:IGNORE ...) CL-USER> (+ 1 #+#:ignore 2 3) 4
I do use this in practice, and I also use it as a form of documentation on why I'm commenting something out. As a sort of contrived example:
(defun f () #+#:ignore-buggy (progn ...) ; buggy code
(progn ...)) ; working code
Though, this is certainly clunkier than a dedicated #; macro.
Cheers!
Robert Smith quad@symbo1ics.com
On Sun, May 6, 2012 at 1:57 PM, Pascal Costanza <pc@p-cos.net> wrote:
Hi,
I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
Here is a suggested wording.
------------- snip -----------------
#; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place.
#; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.
------------- snip -----------------
The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document.
Any comments or ideas about this?
Best, Pascal
-- Pascal Costanza
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
-- Pascal Costanza
On Sun, 2012-05-06 at 20:57 +0200, Pascal Costanza wrote:
Hi,
I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
Here is a suggested wording.
------------- snip -----------------
#; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place.
#; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.
------------- snip -----------------
The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document.
Awesome idea -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
I'm mildly opposed to trying to impose syntax extensions on the language if the only motivation is slight convenience. ANSI CL is 20 years old, and there are a lot mostly-conforming but old and unsupported implementations out there, and this syntax won't work out of the box. Besides, I find that feature expressions like #+never #+notyet #+nomore or #+bug456 provide useful self documentation about conditionals, while we programmers are often lazy about adding real documentation about changes. But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source. And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable. I know programmers who use it, although I find it lexographically tedious. If God had intended me to spend so much time and energy engaging the shift key, he would have given me three thumbs or he would have given all computers Lispm keyboards.
On Sun, 2012-05-06 at 12:54 -0700, Steve Haflich wrote:
I'm mildly opposed to trying to impose syntax extensions on the language if the only motivation is slight convenience. ANSI CL is 20 years old, and there are a lot mostly-conforming but old and unsupported implementations out there, and this syntax won't work out of the box.
I personally don't care about about modern code being able to run on old implementations, only(if slightly) about old code running on modern implementations, so continuously adding features is fine.
Besides, I find that feature expressions like #+never #+notyet # +nomore or #+bug456 provide useful self documentation about conditionals, while we programmers are often lazy about adding real documentation about changes.
It's difficult to put all necessary explanation inside a single symbol, even a Haiku requires two verses
But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.
Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it
And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable. I know programmers who use it, although I find it lexographically tedious. If God had intended me to spend so much time and energy engaging the shift key, he would have given me three thumbs or he would have given all computers Lispm keyboards.
Many Europeans(like me) manage to write CL even if #\( is shifted, and #\# is on AltGr -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.
Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it
1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes. 2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable. 3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Two wrongs don't make a right — but three lefts do.
On 7 May 2012, at 00:54, Faré wrote:
But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.
Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it
1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes.
This seems to suggest that this only works for compiled code. What about interpreted code?
2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable.
3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition.
Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial). Pascal -- Pascal Costanza
On 7 May 2012, at 08:27, Pascal Costanza wrote:
On 7 May 2012, at 00:54, Faré wrote:
But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.
Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it
1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes.
This seems to suggest that this only works for compiled code. What about interpreted code?
2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable.
3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition.
Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).
Pressed the send button too fast: That's _not_ my primary interest… Pascal -- Pascal Costanza
Pascal Costanza <pc-99OXBJU6cIpeoWH0uzbU5w@public.gmane.org> writes:
Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).
Pressed the send button too fast: That's _not_ my primary interest…
The implementation may be trivial, but its effects are not. (prog1 #; #-(and) 42 11) (prog1 #; #; 42 11) depending on how it's specified may return a surprising result. Ie. the specification of #; would need more than the given one-liner. Since commenting-out an expression is not meant as a comment, but merely disabling TEMPORARILY the experession (while debugging/developping), IMO, it should not use a comment syntax. #; is too close to the ; character used for real comments. I'd even argue that those "commented-out" expressions should not stay in the sources. If we used them it's only because of a deffect of our IDEs/VCS. (You could just delete them, and use the VCS to recover them when needed). With that in mind, #-(and) or #+(or) are not bad: they stand out and they make you wonder if you should not just delete the expression. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
On 7 May 2012 13:58, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
I'd even argue that those "commented-out" expressions should not stay in the sources. If we used them it's only because of a deffect of our IDEs/VCS. (You could just delete them, and use the VCS to recover them when needed).
With that in mind, #-(and) or #+(or) are not bad: they stand out and they make you wonder if you should not just delete the expression.
Where's the +1 button when you need one?! -- Jānis
1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes.
This seems to suggest that this only works for compiled code. What about interpreted code?
I don't know what you call "compiled code", but if that's what you mean, the perform method of load-source-op also does call that hook.
2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable.
3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition.
Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).
The question is how to provide a modular interface to this and other extensions. So far, named-readtables is your best bet for simple reader macros, and reader-interception if you need a complete syntax redesign. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
To be clean, you'd need to update the CL editors so that they don't see the entire remainder of the line as a comment if the Sexpr occupies less than the remainder of the line, and do see whatever following lines are contained in Sexpr as a comment. But otherwise, I'm in favor of whatever makes life easier in programming. Dr. David McClain dbm@refined-audiometrics.com
On Mon, May 7, 2012 at 2:01 PM, David McClain <dbm@refined-audiometrics.com>wrote:
To be clean, you'd need to update the CL editors so that they don't see the entire remainder of the line as a comment if the Sexpr occupies less than the remainder of the line, and do see whatever following lines are contained in Sexpr as a comment. But otherwise, I'm in favor of whatever makes life easier in programming.
So am I, but then, this particular plan does not seem to make life much easier at the expense of creating work for IDE implementers. I'm not saying that it is a lot of work, but then, I think #+(or) or #+(and) is clear enough. One can always create some editor macro that expands #; one of that and be done with that. -Hans
* Steve Haflich <funsyvpu-Er5WDRrDdr8NikgvhZjk3j@choyvp.tznar.bet> [2012-05-06 12:54:00 -0700]:
I'm mildly opposed to trying to impose syntax extensions on the language if the only motivation is slight convenience.
not quite "mildly". any change has a cost and the benefit here is negligible, so I don't see any reason to do this.
Besides, I find that feature expressions like #+never #+notyet #+nomore or #+bug456 provide useful self documentation about conditionals, while we programmers are often lazy about adding real documentation about changes.
+1
And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable.
+1 -- Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11103000 http://www.childpsy.net/ http://mideasttruth.com http://www.PetitionOnline.com/tap12009/ http://truepeace.org Those who can laugh at themselves will never cease to be amused.
On 6 May 2012 21:54, Steve Haflich <shaflich@gmail.com> wrote:
And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable. I know programmers who use it, although I find it lexographically tedious.
FWIW, I personally use #-(and) and #+(and) -- the #\+ and #\- signs are pretty easy to relate to the semantics. -- Jānis
On Sun, May 6, 2012 at 8:57 PM, Pascal Costanza <pc@p-cos.net> wrote:
Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
How would #; expression differ from #+(or) expression which is 100% reliable and standard? - Willem
On 6 May 2012, at 21:26, Willem Broekema wrote:
On Sun, May 6, 2012 at 8:57 PM, Pascal Costanza <pc@p-cos.net> wrote:
Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
How would
#; expression
differ from
#+(or) expression
which is 100% reliable and standard?
It's probably just me, but I find #+(or) and #-(and) confusing - I always have to stop at such a place for a minute to think about what the actual outcome is... Pascal -- Pascal Costanza
In article <AE74261C-E7E8-4A56-B708-B5B135A3FB29@p-cos.net>, Pascal Costanza <pc@p-cos.net> wrote:
Hi,
I'm thinking about writing up a CDR on #;-style comments. Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.
Here is a suggested wording.
------------- snip -----------------
#; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place.
#; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read.
------------- snip -----------------
The text is based on 2.4.8.17 of the HyperSpec. Yes, this would be a fairly short CDR document.
Any comments or ideas about this?
I don't see the need for it. #+nil will work just fine de facto. And for the paranoid, there's the trick that Robert Smith mentioned (#+#:foo). The only thing that could make it interesting because it'd add something to the table, is to allow e.g. #2; to comment out the next two forms. It sounds a bit insane, though. T PS. According to Figure 2-19 in CLHS 2.4.8, #, is not explicitly reserved for the user (most likely as #, was something akin to LOAD-TIME-VALUE in CLtL1.) I just wanted to point that out in case you do write a CDR where you might want to mention it.
Best, Pascal
-- Pascal Costanza
Message: 1 Date: Sun, 6 May 2012 20:57:27 +0200 From: Pascal Costanza <pc@p-cos.net> Here is a suggested wording. ------------- snip ----------------- #; is used to comment out single expressions; the syntax is /#; expression/. This textual notation is treated as whitespace; that is, it is as if the ``#; expression'' did not appear and only a space appeared in its place. #; operates by skipping over the form. Skipping over the form is accomplished by binding *read-suppress* to true and then calling read. ------------- snip ----------------- It might be better to simply state that "#;" behaves exactly the same way that "#+(or)" behaves. That way any future clarifications about various edge cases can all be fixed in the same place. Any comments or ideas about this? It also might be better to instead try to standardize on a short feature name that is guaranteed to -never- appear on the features list. For example, if it was guaranteed that :% would never appear as a member of *FEATURES*, then you could use "#+%". (Or "#+_", "#+-", "#+||", "#++", ...) This has the advantage that it has a very low cost of adoption. All known Common Lisp inplementations effectively already implement it. To truly implement it they would only have to make a promise.
In my view, #; would be handy: #+(or) trips me up visually and is an idiom. I would rather remember that #; is a nulled/commented out form (like ; is for lines), and reserve #+(or) for connoting other things. I would not be horrified if it did not get implemented, but I think I would be prone to use it. I don't remember seeing a reference implementation link. I would like to experiment with using one if it exists. Regards, Paul Nathan
Assuming you are a Common Lisp programmer, implementation is a two liner. The question under discussion in this thread is not about implementation difficulty. It's about whether this syntax is attractive enough, unambiguously understandable enough, and would likely become widely enough adopted to become part of the portable understood-by-everyone-at-sight language.
On Tue, May 8, 2012 at 12:49 PM, Steve Haflich <shaflich@gmail.com> wrote:
Assuming you are a Common Lisp programmer, implementation is a two liner.
The question under discussion in this thread is not about implementation difficulty. It's about whether this syntax is attractive enough, unambiguously understandable enough, and would likely become widely enough adopted to become part of the portable understood-by-everyone-at-sight language.
A more important question, to me, is how would such a language relate to Common Lisp. Is the point to just write a .asd system that exports the functionality through named-readtables? If so, there is nothing to discuss here. Just do it and announce your system. Is the point to evolve the Common Lisp standard into some kind of CLtL4, and leave behind other implementations as only being ansi-common-lisp? I just don't see that happening, what with 9 active implementations to coordinate. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Moderation in temper is always a virtue; but moderation in principle is always a vice. — Thomas Paine
On Tue, May 8, 2012 at 7:41 PM, Faré <fahree@gmail.com> wrote:
Is the point to evolve the Common Lisp standard into some kind of CLtL4,
Huh? Did I miss a CLtL3...? On topic: the proposed syntactic addition is nice, but imho too trivial and too easily provided as a library to bother with a CDR (that would need to be included in each implementation). Alessio -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
On 8 May 2012, at 20:02, Alessio Stalla wrote:
On topic: the proposed syntactic addition is nice, but imho too trivial and too easily provided as a library to bother with a CDR (that would need to be included in each implementation).
Interesting discussion so far. (Alessio, I'm not responding to you directly, just as a stub for the discussion, so to speak… ;) I can perfectly understand those who voiced their opinion that the existing mechanisms for commenting out s-expressions are good enough. (I especially liked the #+| here is a bug | variant that puts a comment in the feature expression.) However, the suggestion that #; could just be put in a library is not a valid counter argument. The main reason for adding #; to a specification (and thus suggesting it as a quasi-standard for the language) is that it should be straightforward and simple to use it. Adding #; in any way makes only sense if it can be used in a considerably faster way than any other of the existing options. If I want to comment out an s-expression, I probably want to do this during development because I quickly want to try out a variant of my code. I don't want to be interrupted in my flow of thinking about the problem at hand when doing so. That's the very reason why I never use the #+(and) and #-(or) options, because they require me to think at least for a few seconds which way the operators go, and that disrupts what I'm actually interested in [1]. Likewise, I think, with the other options. I already find that placing a pair of #| |# around the s-expression in question takes far too much time than necessary. I haven't decided yet whether I should go forward with the CDR or not... Pascal [1] They are intentionally chosen wrong in this sentence, and if you missed that, it proves my point. -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 13 May 2012 19:47, Pascal Costanza <pc@p-cos.net> wrote:
On 8 May 2012, at 20:02, Alessio Stalla wrote:
On topic: the proposed syntactic addition is nice, but imho too trivial and too easily provided as a library to bother with a CDR (that would need to be included in each implementation).
Interesting discussion so far.
I'm sorry I'm contributing to this boring discussion. But I think it is turning from boring into entertaining.
I can perfectly understand those who voiced their opinion that the existing mechanisms for commenting out s-expressions are good enough. (I especially liked the #+| here is a bug | variant that puts a comment in the feature expression.)
However, the suggestion that #; could just be put in a library is not a valid counter argument. The main reason for adding #; to a specification (and thus suggesting it as a quasi-standard for the language) is that it should be straightforward and simple to use it.
That's exactly the reason why it should not be added to the specification since it already provides means of addressing the issue.
Adding #; in any way makes only sense if it can be used in a considerably faster way than any other of the existing options.
I already use a single key (M-; - paredit-comment-dwim) key for my commenting needs. If I was commenting out single expressions frequently enough, I'd probably assign it to a key, too (probably C-M-; - which would be consistent with other key bindings that act on expressions). Therefore I do not see how using #; as instead of #-(and) or #+(or) would be "considerably faster", since I expect the editor to insert all of them with the same percievable speed.
If I want to comment out an s-expression, I probably want to do this during development because I quickly want to try out a variant of my code. I don't want to be interrupted in my flow of thinking about the problem at hand when doing so.
Yes, the keyboard shortcuts have a tendency to get into the subconscious so we don't think about them at all.
That's the very reason why I never use the #+(and) and #-(or) options, because they require me to think at least for a few seconds which way the operators go, and that disrupts what I'm actually interested in [1].
As I already noted, I personally use #-(and) when I do need/want to comment out a [lengthy] expression. And I will teach you a trick I have learned from other great minds that will allow you to deal with this little inconvenience. It takes two steps: 1. Try to associate the "minus" sign with removing something, and "plus" sign with adding something. 2. Forget about (or), and use only (and). You're done. Now, if you want to remove an expression, you use #-(and) (notice the minus sign!). If you want to have it back [temporarily], you change that to #+(and) (see, the minus has been changed into plus!). Also, if the association in step 1 somehow contradicts your experience, and is the other way around, all you have to do is forget about (and) and use (or) instead. In any case, this is a one time investment, and you think about it only once, and then use for the rest of your life. I accept your advance gratitude on all the hours you will save not thinking about this issue in your future programming endeavours. You are welcome!
Likewise, I think, with the other options. I already find that placing a pair of #| |# around the s-expression in question takes far too much time than necessary.
Yes, using this facility also is troublesome for different reason: in my experience it has confused the editor on too many occasions that I have completely stopped using it. Not that I miss it since I learned of M-; (usually used in together with expression selection commands).
[1] They are intentionally chosen wrong in this sentence, and if you missed that, it proves my point.
Now that I have revealed my secret trick, you yourself can see that your point is not only not proven, but the very existence of it is in question. -- Jānis
It is probably just me but I do find it fascinating that the most active topic in CL Pro is how NOT to execute Lisp code. Alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
* Pascal Costanza <cp@c-pbf.arg> [2012-05-06 20:57:27 +0200]:
I'm thinking about writing up a CDR on #;-style comments.
the issue is so inconsequential, it saddens me to see so many lispers so eagerly discussing it. this is not even bike shed. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000 http://www.childpsy.net/ http://mideasttruth.com http://ffii.org http://iris.org.il http://thereligionofpeace.com http://honestreporting.com The early bird may get the worm, but the second mouse gets the cheese.
Sam Steingold <sds-mXXj517/zsQ@public.gmane.org> writes:
* Pascal Costanza <cp-Bj2O8gVV4VHYtjvyW6yDsg@public.gmane.org> [2012-05-06 20:57:27 +0200]:
I'm thinking about writing up a CDR on #;-style comments.
But it's not unproductive. Now we know that it should be specified as equivalent to #-(and), that assuming it's CDR-10, that it can be used as: #+cdr-10 #; #-cdr-10 #-(and) "commented out sexp" oops, that'll break :-( Ok, just joking, it would be used as: #-cdr-10 (eval-when (:compile-toplevel :load-toplevel :execute) (error "please load CDR-10 before this source")) #;"commented out sexp" We've consider the cost to implementors (close to nul), but the cost to users (ie. programmers writing conforming code) is higher. Instead of the above I think I'll keep writing: #-(and) "commented out sexp" -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Meta: it's one thing to talk about things some people consider inconsequential. It is another to sidetrack that discussion to be about whether it is inconsequential or not. Just saying. There aren't too many CDRs. It doesn't matter if they aren't earth shaking or if they're something that can live in libraries. Let's have some more. Sturgeon's Law applies to everything, even Lisp. Cheers, -- nikodemus (Though if I had to vote on "what sort of CDR should Pascal Costanza write", I would vote on something CLOS or MOP related... :))
+1 On May 8, 2012, at 21:26 , Nikodemus Siivola wrote:
Meta: it's one thing to talk about things some people consider inconsequential. It is another to sidetrack that discussion to be about whether it is inconsequential or not.
Just saying.
There aren't too many CDRs. It doesn't matter if they aren't earth shaking or if they're something that can live in libraries. Let's have some more. Sturgeon's Law applies to everything, even Lisp.
Cheers,
-- nikodemus
(Though if I had to vote on "what sort of CDR should Pascal Costanza write", I would vote on something CLOS or MOP related... :))
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.
participants (20)
-
Alan Bawden -
Alessio Stalla -
Alexander Repenning -
David McClain -
Erik Winkels -
Faré -
Hans Hübner -
Janis Dzerins -
Marco Antoniotti -
Nick Levine -
Nikodemus Siivola -
Pascal Costanza -
Pascal J. Bourguignon -
Paul Nathan -
Robert Smith -
Sam Steingold -
Stelian Ionescu -
Steve Haflich -
Tobias C Rittweiler -
Willem Broekema