#; comments...

[Pascal Costanza]

Content preview: 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. [...]

Content analysis details: (-102.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[217.70.178.89 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/634>

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

[Marco Antoniotti]

Content preview: +1 On May 6, 2012, at 20:57 , Pascal Costanza wrote: > Hi,

Post by Pascal Costanza

Post by Pascal Costanza
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.

Post by Pascal Costanza

Post by Pascal Costanza
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?

Post by Pascal Costanza

Post by Pascal Costanza

Best, > Pascal > > -- > Pascal Costanza > > > > > > pro mailing list

[...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/635>

+1

Post by Pascal Costanza
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
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.

[Stelian Ionescu]

Post by Pascal Costanza
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

[Steve Haflich]

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.

[Stelian Ionescu]

Post by Steve Haflich
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.

Post by Steve Haflich
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

Post by Steve Haflich
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

Post by Steve Haflich
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

[Faré]

Post by Stelian Ionescu

Post by Steve Haflich
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.

[Pascal Costanza]

Content preview: 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.
[...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
X-BeenThere: pro-***@public.gmane.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Common Lisp Professionals <pro.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/pro>,
<mailto:pro-request-***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/pro>
List-Post: <mailto:pro-***@public.gmane.org>
List-Help: <mailto:pro-request-***@public.gmane.org?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro>,
<mailto:pro-request-***@public.gmane.org?subject=subscribe>
Errors-To: pro-bounces-***@public.gmane.org
X-Spam-Score: -100.0 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "tiger.common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: 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.
[...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/652>

Post by Faré

Post by Stelian Ionescu

Post by Steve Haflich
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?

Post by Faré
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

[Pascal Costanza]

Content preview: 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

Post by Pascal Costanza

Post by Pascal Costanza

Post by Stelian Ionescu

Post by Steve Haflich

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.

Post by Pascal Costanza

Post by Pascal Costanza
This seems to suggest that this only works for compiled code. What about

interpreted code? > >> 2- Since well before that, there is named-readtables.

Post by Pascal Costanza

Post by Pascal Costanza
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). [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.196 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
X-BeenThere: pro-***@public.gmane.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Common Lisp Professionals <pro.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/pro>,
<mailto:pro-request-***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/pro>
List-Post: <mailto:pro-***@public.gmane.org>
List-Help: <mailto:pro-request-***@public.gmane.org?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro>,
<mailto:pro-request-***@public.gmane.org?subject=subscribe>
Errors-To: pro-bounces-***@public.gmane.org
X-Spam-Score: -100.0 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "tiger.common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: 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

Post by Pascal Costanza

Post by Pascal Costanza

Post by Stelian Ionescu

Post by Steve Haflich

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.

Post by Pascal Costanza

Post by Pascal Costanza
This seems to suggest that this only works for compiled code. What about

interpreted code? > >> 2- Since well before that, there is named-readtables.

Post by Pascal Costanza

Post by Pascal Costanza
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). [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.196 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 SINGLE_HEADER_2K A single header contains 2K-3K characters
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/653>

Post by Pascal Costanza

Post by Pascal Costanza

Post by Stelian Ionescu

Post by Steve Haflich
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?

Post by Pascal Costanza
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 J. Bourguignon]

Post by Pascal Costanza

Post by Pascal Costanza
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.

[Janis Dzerins]

Post by Pascal J. Bourguignon
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

[Faré]

Post by Pascal Costanza

Post by Faré
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.

Post by Pascal Costanza

Post by Faré
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

[David McClain]

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-h9Lvq2qNYxl8mnqqp10EyDJtdDapTP/***@public.gmane.org

[Hans Hübner]

On Mon, May 7, 2012 at 2:01 PM, David McClain

Post by David McClain
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

[Sam Steingold]

Content preview: > * Steve Haflich <funsyvpu-Er5WDRrDdr8NikgvhZjk3j-Sn5dYDs+***@public.gmane.org>
[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.
[...]

Content analysis details: (-98.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.216.179 listed in list.dnswl.org]
1.8 URIBL_BLACK Contains an URL listed in the URIBL blacklist
[URIs: childpsy.net]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(sam.steingold[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/646>

Post by Steve Haflich
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.

Post by Steve Haflich
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

Post by Steve Haflich
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

[Janis Dzerins]

Post by Steve Haflich
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

[Pascal Costanza]

Content preview: Hi, I haven't thought of that idea. But it does look ugly,
doesn't it? ;) Pascal [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.196 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/638>

Hi,

I haven't thought of that idea. But it does look ugly, doesn't it? ;)

Pascal

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
(defun f ()
#+#:ignore-buggy
(progn ...) ; buggy code
(progn ...)) ; working code
Though, this is certainly clunkier than a dedicated #; macro.
Cheers!
Robert Smith

Post by Pascal Costanza
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
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

--
Pascal Costanza

[Pascal Costanza]

Content preview: On 6 May 2012, at 21:26, Willem Broekema wrote: > On Sun,
May 6, 2012 at 8:57 PM, Pascal Costanza <pc-***@public.gmane.org> 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?

[...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/639>

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

[Willem Broekema]

Content preview: On Sun, May 6, 2012 at 8:57 PM, Pascal Costanza 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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.160.51 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(metawilm[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/641>

Post by Pascal Costanza
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

[Robert Smith]

Content preview: 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. [...]

Content analysis details: (-0.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[74.125.82.53 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(quadricode[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/642>

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

Post by Pascal Costanza
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
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

[Nick Levine]

Content preview: > #; operates by skipping over the form. Skipping over the
form is > accomplished by binding *read-suppress* to true and then calling

read. So in particular (#; #; 1 2 3) [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/644>

#; operates by skipping over the form. Skipping over the form is
accomplished by binding *read-suppress* to true and then calling
read.

So in particular

(#; #; 1 2 3)

reads as (3)?

- n

[Tobias C Rittweiler]

Content preview: In article <AE74261C-E7E8-4A56-B708-B5B135A3FB29-***@public.gmane.org>,
Pascal Costanza <pc-***@public.gmane.org> 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? [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/650>

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

[Alan Bawden]

Content preview: Message: 1 Date: Sun, 6 May 2012 20:57:27 +0200 From: Pascal
Costanza <pc-***@public.gmane.org> Here is a suggested wording. snip [...]

Content analysis details: (-2.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[72.249.182.111 listed in list.dnswl.org]
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/662>

Message: 1
Date: Sun, 6 May 2012 20:57:27 +0200
From: Pascal Costanza <pc-***@public.gmane.org>

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.

[Paul Nathan]

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

[Steve Haflich]

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.

[Faré]

Post by Steve Haflich
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

[Alessio Stalla]

Content preview: On Tue, May 8, 2012 at 7:41 PM, Faré 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). [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.216.44 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(alessiostalla[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-BeenThere: pro-***@public.gmane.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Common Lisp Professionals <pro.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/pro>,
<mailto:pro-request-***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/pro>
List-Post: <mailto:pro-***@public.gmane.org>
List-Help: <mailto:pro-request-***@public.gmane.org?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro>,
<mailto:pro-request-***@public.gmane.org?subject=subscribe>
Errors-To: pro-bounces-***@public.gmane.org
X-Spam-Score: -100.7 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "tiger.common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: On Tue, May 8, 2012 at 7:41 PM, Faré 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). [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.216.44 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(alessiostalla[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/668>

Post by Faré
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

[Pascal Costanza]

Content preview: 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). [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/671>

Post by Alessio Stalla
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.

[Erik Winkels]

Post by Pascal Costanza
I already find that placing a pair of #| |# around the s-expression in

question takes far too much time than necessary. Even if you'd bind that action
to a quick key? [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[194.109.24.34 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/673>

Post by Pascal Costanza
I already find that placing a pair of #| |# around the s-expression in question takes far too much time than necessary.

Even if you'd bind that action to a quick key?

[Janis Dzerins]

Post by Pascal Costanza

Post by Alessio Stalla
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.

Post by Pascal Costanza
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.

Post by Pascal Costanza
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.

Post by Pascal Costanza
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.

Post by Pascal Costanza
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!

Post by Pascal Costanza
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).

Post by Pascal Costanza
[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

[Alexander Repenning]

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

[Sam Steingold]

Post by Pascal Costanza

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. [...]

Content analysis details: (-98.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.216.44 listed in list.dnswl.org]
1.8 URIBL_BLACK Contains an URL listed in the URIBL blacklist
[URIs: childpsy.net]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(sam.steingold[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/665>

Post by Pascal Costanza
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.

[Pascal J. Bourguignon]

Content preview: 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.
[...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/667>

Post by Pascal Costanza
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"

[Nikodemus Siivola]

Content preview: 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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.214.179 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/669>

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... :))

[Marco Antoniotti]

Content preview: +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.

Post by Nikodemus Siivola

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-***@public.gmane.org > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
[...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/670>

+1

Post by Nikodemus Siivola
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
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.