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