I just spotted the #; in R6RS and found it a great idea: being
able to specify that ";" should be reserved for actual comments
as opposed to "#;" meant to comment-out code while developing
it, meaning that if I ever forget to clean-up the code once it
works the way I want it to, at least "#;" will stay as a hint
that this is not an explanatory comment, but something I just
forgot to clean-up. Great!
I thought that it ought to be trivial to implement in CL ...
... 35 minutes later, I arrived at:
;;; stolen from CLHS:
http://www.lispworks.com/documentation/HyperSpec/Body/f_set__1.htm
(defun my-semicolon-reader (stream char n)
(declare (ignore char n))
;; First swallow the rest of the current input line.
;; End-of-file is acceptable for terminating the comment.
(do () ((char= (read-char stream nil #\Newline t) #\Newline)))
;; Return zero values.
(values))
#.(set-dispatch-macro-character #\# #\; #'my-semicolon-reader)
(defun test-fn ()
(format t "This is line 1 ~%")
(format t "This is line 2 ~%")
(format t "This is line 3 ~%"))
(defun test-fn-2 ()
(format t "This is line 1 ~%")
#; (format t "This is line 2 ~%")
(format t "This is line 3 ~%"))
CL-USER 1 > (test-fn)
This is line 1
This is line 2
This is line 3
nil
CL-USER 2 > (test-fn-2)
This is line 1
This is line 3
nil
So what did I "waste" 35 minutes on?
- got confused about the distinction between
set-macro-character
and set-dispatch-macro-character
- confused again by the difference bewteen
set-dispatch-macro-character
and make-dispatch-macro-character
- confused as to why
CL-USER 3 > (get-macro-character #\;)
system::read-comment
nil
would return a function that the compiler would then
choke on when installed as the function for #;
and found out that set-macro-character wants a function
of TWO arguments whereas set-dispatch-macro-character wants
just a function:
"function---a function designator or nil",
only to show in the example section that this function
ought to take a THIRD argument (called "n" !?!?!). Wandering
into 2.1.4.4 was NOT helpful in seeing this. Only the
example gave the clue away.
- confused as to why I should use #. to install
my code. I think I now guess the purpose of #. but
it is not clear why just issuing a
(set-dispatch-macro-character #\# #\; #'my-semicolon-reader)
without a leading #. would not work when I just *load*
the file
- beginning to get a feel for what this "eval-when" thingie
is meant to be a solution for
And then started to wish there was some tutorial somewhere
that started out by: here's the list of concepts that are
REALLY different in CL that you must positively master before
even thinking writing non toy examples...
On the bright side, having survived all those "put-off" shows
the "magnetic" appeal of CL, which, despites all those documentation
flows and historically preserved quirks still manages to force
me keeping trying :-)
--
JFB
On Dec 30, 6:13 am, verec <·····@mac.com> wrote:
> I just spotted the #; in R6RS and found it a great idea: being
> able to specify that ";" should be reserved for actual comments
> as opposed to "#;" meant to comment-out code while developing
> it, meaning that if I ever forget to clean-up the code once it
> works the way I want it to, at least "#;" will stay as a hint
> that this is not an explanatory comment, but something I just
> forgot to clean-up. Great!
How silly!
What is the reason why ;# couldn't serve exactly the same purpose?
No new reader macros required.
Kaz Kylheku wrote:
> How silly!
> What is the reason why ;# couldn't serve exactly the same purpose?
> No new reader macros required.
I think maybe I'm missing something. ;# would introduce a comment
that runs to the next line break whereas the R6RS #; form introduces
a comment that runs to the end of the following datum.
So something like
(+ 1 2 #;bogus 4 5) => 12
whereas something like
(+ 1 2 ;#bogus 4 5) can't even be evaluated; it's incomplete.
I'm not seeing the equivalence here.
Bear
In article <·························@news.sonic.net>,
Ray Dillinger <····@sonic.net> wrote:
> Kaz Kylheku wrote:
> > How silly!
>
> > What is the reason why ;# couldn't serve exactly the same purpose?
> > No new reader macros required.
>
> I think maybe I'm missing something. ;# would introduce a comment
> that runs to the next line break whereas the R6RS #; form introduces
> a comment that runs to the end of the following datum.
>
> So something like
>
> (+ 1 2 #;bogus 4 5) => 12
>
> whereas something like
>
> (+ 1 2 ;#bogus 4 5) can't even be evaluated; it's incomplete.
>
> I'm not seeing the equivalence here.
>
> Bear
Use #+#:\; then.
:-)
rg
Ron Garret <·········@flownet.com> wrote:
+---------------
| Ray Dillinger <····@sonic.net> wrote:
| > I think maybe I'm missing something. ;# would introduce a comment
| > that runs to the next line break whereas the R6RS #; form introduces
| > a comment that runs to the end of the following datum.
| > So something like
| > (+ 1 2 #;bogus 4 5) => 12
| > whereas something like
| > (+ 1 2 ;#bogus 4 5) can't even be evaluated; it's incomplete.
| > I'm not seeing the equivalence here.
|
| Use #+#:\; then.
+---------------
As noted before, #+- is simpler, and #-+ is a matching complement:
> (list 1 2 #+- 3 4 #-+ 5 6)
(1 2 4 5 6)
>
But as Kent has pointed out, all *three* of the above *might*
be faked out with infelicitous PUSHes to *FEATURES*, so the
only[1] really portable ones are #-(and) and #+(and):
> (list 1 2 #-(and) 3 4 #+(and) 5 6)
(1 2 4 5 6)
>
-Rob
[1] Well, only ones with intuitive visual polarities.
As I've mentioned before, I prefer #-(and) & #+(and)
to #+(or) & #-(or), respectively, because the former
are more mnemnonic. When using AND, one turns *off*
a form with minus, and turns *on* a form with plus.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Ron Garret <·········@flownet.com> wrote:
> +---------------
> | Ray Dillinger <····@sonic.net> wrote:
> | > I think maybe I'm missing something. ;# would introduce a comment
> | > that runs to the next line break whereas the R6RS #; form introduces
> | > a comment that runs to the end of the following datum.
> | > So something like
> | > (+ 1 2 #;bogus 4 5) => 12
> | > whereas something like
> | > (+ 1 2 ;#bogus 4 5) can't even be evaluated; it's incomplete.
> | > I'm not seeing the equivalence here.
> |
> | Use #+#:\; then.
> +---------------
>
> As noted before, #+- is simpler, and #-+ is a matching complement:
>
> > (list 1 2 #+- 3 4 #-+ 5 6)
>
> (1 2 4 5 6)
> >
>
> But as Kent has pointed out, all *three* of the above *might*
> be faked out with infelicitous PUSHes to *FEATURES*,
How would you fake #+#:\; (or #+#:anything for that matter)?
rg
Ron Garret <·········@flownet.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > Ron Garret <·········@flownet.com> wrote:
| > +---------------
| > | Use #+#:\; then.
| > +---------------
...
| > But as Kent has pointed out, all *three* of the above *might*
| > be faked out with infelicitous PUSHes to *FEATURES*,
|
| How would you fake #+#:\; (or #+#:anything for that matter)?
+---------------
Oops! Right you are! #+#:\; should be as safe as #+(or) or #-(and).
And #-#:\; can also be used to do the same as #-(or) or #+(and).
But #+#:\; is no shorter than #+(or) -- how about #+#:- instead,
which is *almost* as short as #+- but can't be faked and has the
same useful "from + to -" mnemonic value.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ron Garret <·········@flownet.com> writes:
> How would you fake #+#:\; (or #+#:anything for that matter)?
That's quite fun, actually. That would probably work. It's ugly, yet
cute, at the same time. I'm not sure I'd ever use it. But I'll give
it some thought.
Did you make that up or did you get it from somewhere else? I don't
recall seeing the suggestion before.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > How would you fake #+#:\; (or #+#:anything for that matter)?
>
> That's quite fun, actually. That would probably work. It's ugly, yet
> cute, at the same time. I'm not sure I'd ever use it. But I'll give
> it some thought.
>
> Did you make that up or did you get it from somewhere else? I don't
> recall seeing the suggestion before.
I made up the reader macro combination, but not the general technique of
using an uninterned symbol as a guaranteed-unique object. But my intent
was more to be humorous than to make a serious suggestion. Personally,
I think #+#:\; is horribly ugly, and I would cast a very jaundiced eye
on any code that actually used it.
rg
Ron Garret <·········@flownet.com> writes:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > How would you fake #+#:\; (or #+#:anything for that matter)?
>>
>> That's quite fun, actually. That would probably work. It's ugly, yet
>> cute, at the same time. I'm not sure I'd ever use it. But I'll give
>> it some thought.
>>
>> Did you make that up or did you get it from somewhere else? I don't
>> recall seeing the suggestion before.
>
> I made up the reader macro combination, but not the general technique of
> using an uninterned symbol as a guaranteed-unique object. But my intent
> was more to be humorous than to make a serious suggestion. Personally,
> I think #+#:\; is horribly ugly, and I would cast a very jaundiced eye
> on any code that actually used it.
Be very afraid. Now have I, after reading this thread and having seen
"#+#:" a few times, begun to think #+#:ignore is the best bet I've
seen...
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Kent M Pitman wrote:
> Ron Garret <·········@flownet.com> writes:
>
>> How would you fake #+#:\; (or #+#:anything for that matter)?
>
> That's quite fun, actually. That would probably work. It's ugly, yet
> cute, at the same time. I'm not sure I'd ever use it. But I'll give
> it some thought.
>
> Did you make that up or did you get it from somewhere else? I don't
> recall seeing the suggestion before.
It's indeed cute. What about #+#:ignore ?
BTW, how likely is it that a Common Lisp implementation does _not_ have
:common-lisp in *features* ? Depending on that, one could also use
#-common-lisp ...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> BTW, how likely is it that a Common Lisp implementation does _not_
> have :common-lisp in *features* ? Depending on that, one could also
> use #-common-lisp ...
The problem is that one of the things about #+/#- that are not as obvious
in modern code, but could come into play again (and might not be gone in
all quarters) is that they are notations intended also as interchange
among Lisp dialects. For example, :COMMON-LISP is not present in Zetalisp
or Maclisp, which do have #+ in them. These notations were used as
compatibility for porting code back and forth routinely. And if a new
dialect came along, it would not surprise me to find it again used, so
leaning heavily on that marker seems ill-advised because code you thought
you had commented out might not be...
As an aside, I'll note that non-CL implementations can differ widely. A
common thing I used to write in my Maclisp code was stuff like:
#+LISPM FOO: BAR
because the Lisp Machine Zetalisp dialect treated foo: as just a call to
READ in the FOO package, so even foo:(a b c) was permitted. A consequence
was that Zetalisp would read that expression above as FOO:BAR while Maclisp
would read it as just BAR. I sometimes even saw:
#+LISPM : FOO
used to get :FOO on the LispM and FOO in MACLISP. I think this was useful
in structs, which in Maclisp didn't use keywords for creation. In a dialect,
even a future dialect, that eschewed packages, I could imagine similar things
being done. Or perhaps even...
'(#+COMMON-LISP #.(LET ((*PACKAGE* "KEYWORD")) (READ)) BAR
#-COMMON-LISP #.(LET ((*PACKAGE* "KEYWORD")) (READ)) BAR)
=> (:BAR BAR)
Well, maybe not in code. But perhaps in a macro at boostrap/foothold time.
It would, of course, depend on the details of whether such a dialect
agreed with CL on the treatment of #+/#-/#./etc
Kent M Pitman <······@nhplace.com> writes:
> As an aside, I'll note that non-CL implementations can differ widely. A
> common thing I used to write in my Maclisp code was stuff like:
>
> #+LISPM FOO: BAR
>
> because the Lisp Machine Zetalisp dialect treated foo: as just a call to
> READ in the FOO package, so even foo:(a b c) was permitted. A consequence
> was that Zetalisp would read that expression above as FOO:BAR while Maclisp
> would read it as just BAR. I sometimes even saw:
>
> #+LISPM : FOO
>
> used to get :FOO on the LispM and FOO in MACLISP. I think this was useful
> in structs, which in Maclisp didn't use keywords for creation.
This was interesting. It looks really handy. How was this treated in the
discussions creating the CL standard? I thought it would have been handy
to have had in CL, or am I missing some none to subtle reason it's a bad
idea?
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
> Kent M Pitman <······@nhplace.com> writes:
> > #+LISPM FOO: BAR
> > #+LISPM : FOO
> This was interesting. It looks really handy. How was this treated in the
> discussions creating the CL standard? I thought it would have been handy
> to have had in CL, or am I missing some none to subtle reason it's a bad
> idea?
On the Lisp Machine, Zetalisp did this, but Symbolics Common Lisp
didn't. (There were about 7 co-resident dialects of Lisp on the
Symbolics Lisp Machines toward the end of my time at Symbolics [1992],
each with subtly different natures, including different readers, but
these were the principal two.)
The reason for the transition, I believe, is that it was hard to make
the :: vs : distinction in the Zetalisp style. Zetalisp was already
using single-colon to mean "just call READ", which implicitly meant
what CL calls "::". CL picked "::" to make it uglier and less likely
you'd do it, since it was a data abstraction violation. The ":"
syntax was intended to be careful about picking exported interfaces,
and if you called READ, the problem was that every symbol in the READ
needed to be an external symbol... or might need to. It could be
defined in any way, of course, but intuitions tend to constrain things
somewhat so that you can't just do something utterly arbitrary without
annoying people.
I don't recall if there was a cleanup issue relating to getting this
other style of reader into CL. If there was, of course, it failed. I
just don't know if it got to that level of scrutiny. Certainly it was
discussed informally, though; the result was not by accident. But I
dno't know more of the reasoning than what's in the previous
paragraph, and even that is just my own personal recollection of my
own personal gestalt of a bunch of informal communications... which is
not exactly authoritative. Somewhere I have written records, of course.
Kent M Pitman <······@nhplace.com> writes:
> Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
>
>> Kent M Pitman <······@nhplace.com> writes:
>> > #+LISPM FOO: BAR
>> > #+LISPM : FOO
>> This was interesting. It looks really handy. How was this treated in the
>> discussions creating the CL standard? I thought it would have been handy
>> to have had in CL, or am I missing some none to subtle reason it's a bad
>> idea?
>
> On the Lisp Machine, Zetalisp did this, but Symbolics Common Lisp
> didn't. (There were about 7 co-resident dialects of Lisp on the
> Symbolics Lisp Machines toward the end of my time at Symbolics [1992],
> each with subtly different natures, including different readers, but
> these were the principal two.)
Seven!? Amazing.
> The reason for the transition, I believe, is that it was hard to make
> the :: vs : distinction in the Zetalisp style. Zetalisp was already
> using single-colon to mean "just call READ", which implicitly meant
> what CL calls "::". CL picked "::" to make it uglier and less likely
> you'd do it, since it was a data abstraction violation. The ":"
> syntax was intended to be careful about picking exported interfaces,
> and if you called READ, the problem was that every symbol in the READ
> needed to be an external symbol... or might need to. It could be
> defined in any way, of course, but intuitions tend to constrain things
> somewhat so that you can't just do something utterly arbitrary without
> annoying people.
>
> I don't recall if there was a cleanup issue relating to getting this
> other style of reader into CL. If there was, of course, it failed. I
> just don't know if it got to that level of scrutiny. Certainly it was
> discussed informally, though; the result was not by accident. But I
> dno't know more of the reasoning than what's in the previous
> paragraph, and even that is just my own personal recollection of my
> own personal gestalt of a bunch of informal communications... which is
> not exactly authoritative. Somewhere I have written records, of course.
Thanks for your "recollection of a personal gestalt"! Appreciated.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Sat, 12 Jan 2008 16:25:17 +0100, Pascal Costanza wrote:
> BTW, how likely is it that a Common Lisp implementation does _not_ have
> :common-lisp in *features* ? Depending on that, one could also use
> #-common-lisp ...
>
>
> Pascal
>
~ $>gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Nov 10 2006 14:25:02
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
>*features*
(:COMPILER :NUMLIB :SDEBUG :DEFPACKAGE :GNU-LD :XGCL :UNEXEC :BFD
:NATIVE-RELOC :READLINE :TRUNCATE_USE_C :CLX-LITTLE-ENDIAN :BSD
:GNU :LINUX :X86_64 :SGC :IEEE-FLOATING-POINT :UNIX :GMP :GCL
:AKCL
:COMMON
:KCL)
>
Never say never!
Maybe it's because the standard build of gcl is not ANSI compliant. There
is an ANSI build that's quite close. Here is its features list
>*features*
(:COMPILER :NUMLIB :CLOS-CONDITIONS :PCL-STRUCTURES
:PORTABLE-COMMONLOOPS :PCL :TURBO-CLOSURE-ENV-SIZE :TURBO-CLOSURE
:SDEBUG :DEFPACKAGE :SETF
:ANSI-CL
:COMMON-LISP
:C99 :GNU-LD
:UNEXEC :BFD :NATIVE-RELOC :READLINE :TRUNCATE_USE_C :INTDIV
:DYNAMIC-EXTENT :SWITCH :CLX-LITTLE-ENDIAN :BSD :GNU :LINUX :X86_64
:SGC :IEEE-FLOATING-POINT :UNIX :GPROF :GMP :GCL :AKCL
:COMMON
:KCL)
>
Tim Josling
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> I just spotted the #; in R6RS and found it a great idea: being
> able to specify that ";" should be reserved for actual comments
> as opposed to "#;" meant to comment-out code while developing
> it, meaning that if I ever forget to clean-up the code once it
> works the way I want it to, at least "#;" will stay as a hint
> that this is not an explanatory comment, but something I just
> forgot to clean-up. Great!
>
> I thought that it ought to be trivial to implement in CL ...
Lisp expressions are not based on lines.
(+ 1 2 #; 3 4
)
What should the result be?
3 or 7 ?
7 I'd say.
>
> ... 35 minutes later, I arrived at:
>
> ;;; stolen from CLHS:
> http://www.lispworks.com/documentation/HyperSpec/Body/f_set__1.htm
>
> (defun my-semicolon-reader (stream char n)
> (declare (ignore char n))
> ;; First swallow the rest of the current input line.
> ;; End-of-file is acceptable for terminating the comment.
> (do () ((char= (read-char stream nil #\Newline t) #\Newline)))
> ;; Return zero values.
> (values))
>
> #.(set-dispatch-macro-character #\# #\; #'my-semicolon-reader)
>
> (defun test-fn ()
> (format t "This is line 1 ~%")
> (format t "This is line 2 ~%")
> (format t "This is line 3 ~%"))
>
> (defun test-fn-2 ()
> (format t "This is line 1 ~%")
> #; (format t "This is line 2 ~%")
> (format t "This is line 3 ~%"))
>
> CL-USER 1 > (test-fn)
> This is line 1
> This is line 2
> This is line 3
> nil
>
> CL-USER 2 > (test-fn-2)
> This is line 1
> This is line 3
> nil
>
> So what did I "waste" 35 minutes on?
>
> - got confused about the distinction between
> set-macro-character
> and set-dispatch-macro-character
>
> - confused again by the difference bewteen
> set-dispatch-macro-character
> and make-dispatch-macro-character
>
> - confused as to why
> CL-USER 3 > (get-macro-character #\;)
> system::read-comment
> nil
> would return a function that the compiler would then
> choke on when installed as the function for #;
>
> and found out that set-macro-character wants a function
> of TWO arguments whereas set-dispatch-macro-character wants
> just a function:
>
> "function---a function designator or nil",
>
> only to show in the example section that this function
> ought to take a THIRD argument (called "n" !?!?!). Wandering
> into 2.1.4.4 was NOT helpful in seeing this. Only the
> example gave the clue away.
>
> - confused as to why I should use #. to install
> my code. I think I now guess the purpose of #. but
> it is not clear why just issuing a
>
> (set-dispatch-macro-character #\# #\; #'my-semicolon-reader)
>
> without a leading #. would not work when I just *load*
> the file
>
> - beginning to get a feel for what this "eval-when" thingie
> is meant to be a solution for
>
> And then started to wish there was some tutorial somewhere
> that started out by: here's the list of concepts that are
> REALLY different in CL that you must positively master before
> even thinking writing non toy examples...
>
> On the bright side, having survived all those "put-off" shows
> the "magnetic" appeal of CL, which, despites all those documentation
> flows and historically preserved quirks still manages to force
> me keeping trying :-)
> --
> JFB
--
http://lispm.dyndns.org/
P� Sun, 30 Dec 2007 15:13:55 +0100, skrev verec <·····@mac.com>:
As Josvig mentioned you need to comment out a sexp, not a line
for this you already have #| (sexp) |#
--------------
John Thingstad
On 2007-12-30 14:56:13 +0000, "John Thingstad" <·······@online.no> said:
> På Sun, 30 Dec 2007 15:13:55 +0100, skrev verec <·····@mac.com>:
>
> As Josvig mentioned you need to comment out a sexp, not a line
>
> for this you already have #| (sexp) |#
>
> --------------
> John Thingstad
This doesn't preclude \#; to actually *be* based
on line! THAT is its defined purpose!
And *I* find it usefull to be able to comment out
a _line_ with something that clearly states
"this not an ordinary line comment, but a comment-out comment".
I have seen many examples using #+nil for this
purpose, but this precisely doesn't work for
incomplete expressions whereas:
(defun foo (n)
(cond
#; treat this special case later
#; ((= n 1)
#; (foo-1 n))
((= n 2)
(foo-2 n))
(t
(general-case n))))
does, rather than
(defun foo (n)
(cond
; treat this special case later
; ((= n 1)
; (foo-1 n))
((= n 2)
(foo-2 n))
(t
(general-case n))))
But the point was more about how non-obvious it
had been for me to go from "it should be trivial
to implement" to whatever it took to make it
work the way I intended it to.
#| and |# do not work _for me_ in this case because
they either force me to scan past the end of some
line to visually spot the terminating |#
(defun foo (n)
(cond
#| treat this special case later
((= n 1)
(foo-1 n)) |#
((= n 2)
(foo-2 n))
(t
(general-case n))))
or force me to add an extra blank line for a solitary |#
(defun foo (n)
(cond
#| treat this special case later
((= n 1)
(foo-1 n))
|#
((= n 2)
(foo-2 n))
(t
(general-case n))))
or worse, have it on the same line as some other
line that is NOT excluded
(defun foo (n)
(cond
#| treat this special case later
((= n 1)
(foo-1 n))
|# ((= n 2)
(foo-2 n))
(t
(general-case n))))
Obviously a matter of taste :-)
--
JFB
On Dec 30, 7:37 am, verec <·····@mac.com> wrote:
> And *I* find it usefull to be able to comment out
> a _line_ with something that clearly states
> "this not an ordinary line comment, but a comment-out comment".
What if the expression you want to comment out spans more than one
line?
The usual way is this:
#+IGNORE
(commented
out form)
> I have seen many examples using #+nil for this
That and #+IGNORE will break if someone adds IGNORE or NIL to
*FEATURES*.
What will not break is #+(or). This actually has the meaning of
ignoring the following expression no matter what.
#+(or S1 S2 ...) means to scan the following expression if any of the
symbols S1 S2 ... are in *FEATURES*. If OR has no arguments, then no
symbol can enable the following statement.
#+NIL breaks in the historic implementation known as the New
Implementation of Lisp which supposedly identified itself with NIL in
*FEATURES*. :)
> purpose, but this precisely doesn't work for
> incomplete expressions whereas:
>
> (defun foo (n)
> (cond
> #; treat this special case later
> #; ((= n 1)
> #; (foo-1 n))
The cond-pair above /is/ a complete expression (the parentheses
balance).
[1]> '(a b #+(or) (c d) (e f))
(A B (E F))
In what way do you perceive that it doesn't work?
When would you ever want to comment out incomplete expressions? The
part which makes them complete would then be left dangling, probably
causing a syntax error, unless there is a compensating hack.
;; comment out incomplete expr
;; (a b
c d)
oops!
Maybe if you wanted to change the nesting level of something,
temporarily?
'( a b
;; (
c
;; )
)
Kaz Kylheku schrieb:
> '( a b
> ;; (
> c
> ;; )
> )
In MS-DOS Batch I once use REM
'( a b REM (add 2))
'( a b REM (add (some-more (still-more)))
How does that look? (add 2) is ignored, but the last ) not.
Can be useful when writing different parts and want to test step by
step.
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| > I have seen many examples using #+nil for this
|
| That and #+IGNORE will break if someone adds IGNORE or NIL to
| *FEATURES*.
|
| What will not break is #+(or). This actually has the meaning of
| ignoring the following expression no matter what.
+---------------
I actually prefer Erik Naggum's suggestion of #-(and) for that,
since the minus implies "turn it off" to me more than #+(or)
[which just feels "backwards"]. That also lets you change only
one character to turn it back on with #+(and), and again the
plus implies "on" to me [rather than using #-(or) for "on"].
But for some time now I've been using an even simpler pair,
namely, #+- to turn a form "off" [mnemonic: "from on to off"
or a "falling edge"] and #-+ to turn a form "on" [mnemonic:
"from off to on" or a "rising edge"], e.g.:
> (list 1 2 #+- 3 4 #-+ 5 6)
(1 2 4 5 6)
>
This will work provided no-one ever puts :+ or :- onto *features*,
which is highly unlikely. (IMHO.)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Kaz Kylheku <········@gmail.com> wrote:
> +---------------
> | > I have seen many examples using #+nil for this
> |
> | That and #+IGNORE will break if someone adds IGNORE or NIL to
> | *FEATURES*.
> |
> | What will not break is #+(or). This actually has the meaning of
> | ignoring the following expression no matter what.
> +---------------
>
> I actually prefer Erik Naggum's suggestion of #-(and) for that,
> since the minus implies "turn it off" to me more than #+(or)
> [which just feels "backwards"]. That also lets you change only
> one character to turn it back on with #+(and), and again the
> plus implies "on" to me [rather than using #-(or) for "on"].
>
> But for some time now I've been using an even simpler pair,
> namely, #+- to turn a form "off" [mnemonic: "from on to off"
> or a "falling edge"] and #-+ to turn a form "on" [mnemonic:
> "from off to on" or a "rising edge"], e.g.:
>
> > (list 1 2 #+- 3 4 #-+ 5 6)
>
> (1 2 4 5 6)
> >
>
> This will work provided no-one ever puts :+ or :- onto *features*,
> which is highly unlikely. (IMHO.)
IMHO, none of these are really good. They are not solutions, they are
just hacks that get you around a limitation in Common Lisp.
The better solution is to add something like #; and in principle, this
is possible via readtables hackery. However, the fact that #; doesn't
get more widely used (like, say, with-gensyms or other similarly simple
extensions) could be understood as a sign that readtables hackery
doesn't really work that well.
I guess the reason is that there is no good way to integrate readtable
extensions / modifications from different sources. ANSI CL requires an
implementation to automatically set readtables back after processing a
compilation unit (or so), which is a good first step, but doesn't seem
to be sufficient.
There should be some kind of MOP for readtables, or something similar,
to be able to better define the scopes of readtable extensions and
modifications.
And no, I don't have a good and sufficiently worked out idea for that yet...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> The better solution is to add something like #; and in principle, this
> is possible via readtables hackery. However, the fact that #; doesn't
> get more widely used (like, say, with-gensyms or other similarly
> simple extensions) could be understood as a sign that readtables
> hackery doesn't really work that well.
Indeed. Another reason is lack of proper readtable support in nowadays
Lisp environments.
To remedy both points, Robert Goldman and me hacked up a portable
library for named readtables. I.e. a way to register readtables very
analogously to how the package namespace works.
So in future every Lisp file should start with
(in-package :foo)
(in-readtable :standard)
And you can define new named readtables via DEFREADTABLE, i.e.
(defreadtable :foo
(:use :standard :quux)
(:macro-char #\$ #'dollar-reader))
And then you can use
(in-package :foo)
(in-readtable :foo)
Furthermore, you'll be able to use emacs-style file variables
-*- Package: :foo, Readtable: :foo -*-
and your environment will hopefully do the right thing.
There's a match for pretty much all FOO-PACKAGE or PACKAGE-FOO functions
in the CL spec. The code is already there, and pretty polished.
Additionally, the code already hooks into Franz's named-readtable
support, so it's already fully operational with ELI (and probably the
Franz's IDE as well.) I'll hack SLIME to support it the comming spring.
Hopefully, other Lisp environments will follow once it's in more
widespread use.
I don't know if the code is anonymously available yet, though. If it is,
I'll post a link; if not, you'll have to wait until I have time to set
up a project at common-lisp.net (which will probably be at the time I'll
hack its support into SLIME.)
-T.
Tobias C. Rittweiler wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> The better solution is to add something like #; and in principle, this
>> is possible via readtables hackery. However, the fact that #; doesn't
>> get more widely used (like, say, with-gensyms or other similarly
>> simple extensions) could be understood as a sign that readtables
>> hackery doesn't really work that well.
>
> Indeed. Another reason is lack of proper readtable support in nowadays
> Lisp environments.
>
> To remedy both points, Robert Goldman and me hacked up a portable
> library for named readtables. I.e. a way to register readtables very
> analogously to how the package namespace works.
>
> So in future every Lisp file should start with
>
> (in-package :foo)
> (in-readtable :standard)
>
> And you can define new named readtables via DEFREADTABLE, i.e.
>
> (defreadtable :foo
> (:use :standard :quux)
> (:macro-char #\$ #'dollar-reader))
>
> And then you can use
>
> (in-package :foo)
> (in-readtable :foo)
>
> Furthermore, you'll be able to use emacs-style file variables
>
> -*- Package: :foo, Readtable: :foo -*-
>
> and your environment will hopefully do the right thing.
>
> There's a match for pretty much all FOO-PACKAGE or PACKAGE-FOO functions
> in the CL spec. The code is already there, and pretty polished.
>
> Additionally, the code already hooks into Franz's named-readtable
> support, so it's already fully operational with ELI (and probably the
> Franz's IDE as well.) I'll hack SLIME to support it the comming spring.
> Hopefully, other Lisp environments will follow once it's in more
> widespread use.
>
> I don't know if the code is anonymously available yet, though. If it is,
> I'll post a link; if not, you'll have to wait until I have time to set
> up a project at common-lisp.net (which will probably be at the time I'll
> hack its support into SLIME.)
This sounds very promising! I'm looking forward to this...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2007-12-30 14:56:13 +0000, "John Thingstad" <·······@online.no> said:
>
> > På Sun, 30 Dec 2007 15:13:55 +0100, skrev verec <·····@mac.com>:
> >
> > As Josvig mentioned you need to comment out a sexp, not a line
> >
> > for this you already have #| (sexp) |#
> >
> > --------------
> > John Thingstad
>
> This doesn't preclude \#; to actually *be* based
> on line! THAT is its defined purpose!
That is not the purpose in R6RS. In R6RS it comments
out a DATUM.
>
> And *I* find it usefull to be able to comment out
> a _line_ with something that clearly states
> "this not an ordinary line comment, but a comment-out comment".
>
> I have seen many examples using #+nil for this
> purpose, but this precisely doesn't work for
> incomplete expressions whereas:
>
> (defun foo (n)
> (cond
> #; treat this special case later
> #; ((= n 1)
> #; (foo-1 n))
> ((= n 2)
> (foo-2 n))
> (t
> (general-case n))))
>
> does, rather than
>
> (defun foo (n)
> (cond
> ; treat this special case later
> ; ((= n 1)
> ; (foo-1 n))
> ((= n 2)
> (foo-2 n))
> (t
> (general-case n))))
Why introduce a special new comment?
Instead of a new #; you could just write, say, ;# .
>
> But the point was more about how non-obvious it
> had been for me to go from "it should be trivial
> to implement" to whatever it took to make it
> work the way I intended it to.
>
> #| and |# do not work _for me_ in this case because
> they either force me to scan past the end of some
> line to visually spot the terminating |#
>
> (defun foo (n)
> (cond
> #| treat this special case later
> ((= n 1)
> (foo-1 n)) |#
> ((= n 2)
> (foo-2 n))
> (t
> (general-case n))))
>
> or force me to add an extra blank line for a solitary |#
>
> (defun foo (n)
> (cond
> #| treat this special case later
> ((= n 1)
> (foo-1 n))
> |#
> ((= n 2)
> (foo-2 n))
> (t
> (general-case n))))
>
> or worse, have it on the same line as some other
> line that is NOT excluded
>
> (defun foo (n)
> (cond
> #| treat this special case later
> ((= n 1)
> (foo-1 n))
> |# ((= n 2)
> (foo-2 n))
> (t
> (general-case n))))
>
> Obviously a matter of taste :-)
> --
> JFB
--
http://lispm.dyndns.org/
On 2007-12-30 16:15:21 +0000, Rainer Joswig <······@lisp.de> said:
> Why introduce a special new comment?
> Instead of a new #; you could just write, say, ;# .
Wow :-) That's an absolutely fair remark! It just didn't
occur to me :-(
The point tough, assuming I did have a legitimate reason
to use a "reader macro" was how convoluted the discovery
process was, for what turns out to be a very simple
"one-liner"...
Thanks for pointing out ;# though :)
--
JFB
verec wrote:
> On 2007-12-30 16:15:21 +0000, Rainer Joswig <······@lisp.de> said:
>
>> Why introduce a special new comment?
>> Instead of a new #; you could just write, say, ;# .
>
> Wow :-) That's an absolutely fair remark! It just didn't
> occur to me :-(
To comment out whole forms (not just the end of a line), you could do
something like #-hacking (form).
- Daniel
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2007-12-30 16:15:21 +0000, Rainer Joswig <······@lisp.de> said:
>
> > Why introduce a special new comment?
> > Instead of a new #; you could just write, say, ;# .
>
> Wow :-) That's an absolutely fair remark! It just didn't
> occur to me :-(
What you could do is adding a warning to #; .
So, whenever the Lisp READer reads a comment like that,
it WARNs.
>
> The point tough, assuming I did have a legitimate reason
> to use a "reader macro" was how convoluted the discovery
> process was, for what turns out to be a very simple
> "one-liner"...
>
> Thanks for pointing out ;# though :)
> --
> JFB
--
http://lispm.dyndns.org/
verec <·····@mac.com> writes:
> I have seen many examples using #+nil for this
> purpose, but this precisely doesn't work for
> incomplete expressions whereas:
Btw, NIL was the New Implementation of Lisp (a lisp implementation for
the VAX some years ago), and #+NIL actually did have an implementation
it was defined in. I don't recommend it for conditionals. #+(or) is
safer, though not terribly intelligible to everyone. #+ignore is something
I've seen enough people use that it's unlikely anyone would make :ignore
feature and expect it to work.
> (defun foo (n)
> (cond
> #; treat this special case later
This previous line makes no sense since it is not code. Perhaps
you meant
#; ; treat this special case later.
> #; ((= n 1)
> #; (foo-1 n))
I'm not sure I totally see the point of this. I can see it makes the
lines easier to see visually on the left margin, but it's very hard to
mechanically check because if I write
#; (foo)
#; (bar)
the question arises: Is this a single commented-out form, in which case
it's ill-formed. Or is it two in a row? You still can't see the end of
it because the thing that appears as the "end" (the second line) is actually
the start/end of the next one.
Personally, I think prefer to just use this: #|| ... ||#
The use the innermost vertical bar pairs ------^.....^
does nothing for Lisp, and #|...|# would theoretically work the same.
But most Emacs editors see the #|| and the ||# as if you'd written
two independent no-character symbols using the || notation, and so they
syntax the part between the double-pairs as if they were not inside vertical
bars, so they will indent the code better in the "..." range. That makes code
coloring work better and makes code-hopping commands work better.
Kent M Pitman <······@nhplace.com> writes:
>> (defun foo (n)
>> (cond
>> #; treat this special case later
>
> This previous line makes no sense since it is not code. Perhaps
> you meant
>
> #; ; treat this special case later.
>
>> #; ((= n 1)
>> #; (foo-1 n))
>
> I'm not sure I totally see the point of this. I can see it makes the
> lines easier to see visually on the left margin,
If we want visual markers, why not just use the normal comment,
somewhat more visually:
;;;;;;;;;;; ((= n 1)
;;;;;;;;;;; (foo-1 n))
Note that emacs lets you easily comment and uncomment (C-u 11 M-; to
get 11 semicolons).
Or you could write:
;;;LATER;;; ((= n 1)
;;;LATER;;; (foo-1 n))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
KMP> the VAX some years ago), and #+NIL actually did have an implementation
KMP> it was defined in. I don't recommend it for conditionals. #+(or) is
KMP> safer, though not terribly intelligible to everyone. #+ignore is
KMP> something I've seen enough people use that it's unlikely anyone would
KMP> make :ignore feature and expect it to work.
#+nil is widely used in SBCL implementation source code, so it's unlikely
SBCL can be compiled with NIL :)
grepping for #+nil through my libraries collection shows that many popular
libs use it, including SLIME, S-XML, parenscript, Iterate, arnesi.. so one
who pushes NIL into features will break quite a lot of software :)
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
> KMP> the VAX some years ago), and #+NIL actually did have an implementation
> KMP> it was defined in. I don't recommend it for conditionals. #+(or) is
> KMP> safer, though not terribly intelligible to everyone. #+ignore is
> KMP> something I've seen enough people use that it's unlikely anyone would
> KMP> make :ignore feature and expect it to work.
>
> #+nil is widely used in SBCL implementation source code, so it's unlikely
> SBCL can be compiled with NIL :)
Well, first, all Lisp program texts are conforming, and certainly I
would not expect all texts of implementations themselves to be conforming.
On the other hand, it's certainly a reasonable claim that no one is
likely to compile much of anything in NIL. Finding a VAX would be
hard, and I'm not sure if there are emulators. And even if you had
one, I don't know if the NIL sources are available. I offered the
remark about the NIL language per se mostly as color.
Part of my intent, of course, was just inject a bit of history, for fun.
But part of the intent, too, with some marginal practical currency is
that the practice of picking an obscure name and using a #+/#-
conditional with it is error-prone because of the semantics of that.
Over the years, I've seen people more than once end up surprised that
their carefully crafted plan to pick a name no one was using didn't
work. Sometimes it's trivial to dig one's way out of it with some
global editing, sometimes not ... it can depend a lot on how gradually
it happens and how many people are involved in the code. Any shared
namespace has the possibility of name collision.
Note, too, that the failure mode may not simply be "does it not read"
but "why was it put there". For example, some people put these things
on old dead code they don't want to use any more but are afraid to
delete, some people temporarily comment out something that's
troublesome, some people on things that is new code not yet installed.
And sometimes they use different conventions for each of those. And
if others are doing the same thing with different intent, it may
clash. That's why, IF you want to go the route of guessing a name no
one is probably going to use you're going to do this at all, #+BROKEN,
#+OBSOLETE, and #+NOT-YET-TESTED might be more clear than #+NIL.
> grepping for #+nil through my libraries collection shows that many popular
> libs use it, including SLIME, S-XML, parenscript, Iterate, arnesi.. so one
> who pushes NIL into features will break quite a lot of software :)
Just as an aside...
(progn (push nil *features*) :done)
=> :DONE
#+NIL :not :missing
=> :MISSING
[It would have to be :NIL you'd push onto *FEATURES* for that to happen.]
At minimum I wanted to say that #+NIL is not the lispy form of
#ifdef 0
since that NIL is more certainly not the NIL boolean, but rather is a
feature name. That was my point about #+(OR), which really is reliable
because it's primitively defined and cannot be overridden... without
redefining the "#" readmacro of course.
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| At minimum I wanted to say that #+NIL is not the lispy form of
| #ifdef 0
| since that NIL is more certainly not the NIL boolean, but rather is a
| feature name. That was my point about #+(OR), which really is reliable
| because it's primitively defined and cannot be overridden...
+---------------
And I just want to repeat that I still prefer the equally-safe
#-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
since the cognitive dissonance of the former pair is less.
With AND, minus is "off" and plus is "on". Easy to remember.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Kent M Pitman <······@nhplace.com> wrote:
> +---------------
> | At minimum I wanted to say that #+NIL is not the lispy form of
> | #ifdef 0
> | since that NIL is more certainly not the NIL boolean, but rather is a
> | feature name. That was my point about #+(OR), which really is reliable
> | because it's primitively defined and cannot be overridden...
> +---------------
>
> And I just want to repeat that I still prefer the equally-safe
> #-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
> since the cognitive dissonance of the former pair is less.
> With AND, minus is "off" and plus is "on". Easy to remember.
As far as I can tell, #-(AND) is underspecified in ANSI CL.
Section 24.1.2.1 in the HyperSpec is actually not very precise about
'and and 'or feature expressions - it doesn't say that they are related
to the 'and and 'or macros, and it doesn't clearly say what happens when
there are no arguments.
In the case of 'and feature expressions, it says: "An and feature
expression succeeds if all of its argument feature-conditionals succeed;
otherwise, it fails." So does (AND) succeed or fail? How many of its
arguments succeed? All or none?
Same problem for 'or feature expressions, as far as I can tell.
I'd strongly prefer #; because I wouldn't have to spend any time at all
thinking about what it actually means. (In my own code, I actually use
#| |# pairs for the same reason.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
+ Pascal Costanza <··@p-cos.net>:
> As far as I can tell, #-(AND) is underspecified in ANSI CL.
Doesn't look underspecified to me.
> Section 24.1.2.1 in the HyperSpec is actually not very precise about
> and and 'or feature expressions - it doesn't say that they are related
> to the 'and and 'or macros, and it doesn't clearly say what happens
> when there are no arguments.
Because there is no need to?
> In the case of 'and feature expressions, it says: "An and feature
> expression succeeds if all of its argument feature-conditionals
> succeed; otherwise, it fails." So does (AND) succeed or fail? How many
> of its arguments succeed? All or none?
Both of the above. The opposite of "none" is not "all", it is
"some". This is quite clear to anyone who has spent a little while
grappling with the notions of "for all" and "there exists" in
mathematics. It may be counterintuititive at first, but every member
of the empty set is in fact a pink elephant.
> Same problem for 'or feature expressions, as far as I can tell.
The problem should be even less there: Clearly, none of the arguments
in (OR) can succeed. How could they? The fact that all the arguments
succeed is not relevant here, since "all" is not the opposite of
"some".
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Kent M Pitman <······@nhplace.com> writes:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>
>> KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
>> KMP> the VAX some years ago), and #+NIL actually did have an implementation
>> KMP> it was defined in. I don't recommend it for conditionals. #+(or) is
>> KMP> safer, though not terribly intelligible to everyone. #+ignore is
>> KMP> something I've seen enough people use that it's unlikely anyone would
>> KMP> make :ignore feature and expect it to work.
>>
>> #+nil is widely used in SBCL implementation source code, so it's unlikely
>> SBCL can be compiled with NIL :)
>
> Well, first, all Lisp program texts are conforming, and certainly I
> would not expect all texts of implementations themselves to be conforming.
>
> On the other hand, it's certainly a reasonable claim that no one is
> likely to compile much of anything in NIL. Finding a VAX would be
> hard, and I'm not sure if there are emulators. And even if you had
> one, I don't know if the NIL sources are available. I offered the
> remark about the NIL language per se mostly as color.
>
> Part of my intent, of course, was just inject a bit of history, for fun.
Of course there is a VAX simulator/emulator!
http://simh.trailing-edge.com/
I have used it myself and have had lot of fun.
I liked the bit of history, as fun.
> But part of the intent, too, with some marginal practical currency is
> that the practice of picking an obscure name and using a #+/#-
> conditional with it is error-prone because of the semantics of that.
> Over the years, I've seen people more than once end up surprised that
> their carefully crafted plan to pick a name no one was using didn't
> work. Sometimes it's trivial to dig one's way out of it with some
> global editing, sometimes not ... it can depend a lot on how gradually
> it happens and how many people are involved in the code. Any shared
> namespace has the possibility of name collision.
>
> Note, too, that the failure mode may not simply be "does it not read"
> but "why was it put there". For example, some people put these things
> on old dead code they don't want to use any more but are afraid to
> delete, some people temporarily comment out something that's
> troublesome, some people on things that is new code not yet installed.
> And sometimes they use different conventions for each of those. And
> if others are doing the same thing with different intent, it may
> clash. That's why, IF you want to go the route of guessing a name no
> one is probably going to use you're going to do this at all, #+BROKEN,
> #+OBSOLETE, and #+NOT-YET-TESTED might be more clear than #+NIL.
True. I have actually often thought when looking at old code that it
would have helped to have had something like that.
Since Rob suggests his prefered solution for a lispy "ifdef" I guess I
could maybe add my own suggestion of using #+`,nil? It must be safe,
right?
Yeah I know it looks like perl or teco or something. Let's stick with #|
and |# instead.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
> Yeah I know it looks like perl or teco or something. Let's stick with #|
> and |# instead.
I personally prefer #||...||# because it tends to highlight/edit/indent
better in various versions of Emacs. YMMV.
Kent M Pitman <······@nhplace.com> writes:
> Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
>
>> Yeah I know it looks like perl or teco or something. Let's stick with #|
>> and |# instead.
>
> I personally prefer #||...||# because it tends to highlight/edit/indent
> better in various versions of Emacs. YMMV.
I tried it, and my emacs didn't seem to think it different from #|...|#
and I didn't want to bother looking down that jar of messy elisp. I'll
remember youe suggestion, though.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Jan 14, 7:17 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
wrote:
> Kent M Pitman <······@nhplace.com> writes:
>
> > Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
>
> >> Yeah I know it looks like perl or teco or something. Let's stick with #|
> >> and |# instead.
>
> > I personally prefer #||...||# because it tends to highlight/edit/indent
> > better in various versions of Emacs. YMMV.
>
> I tried it, and my emacs didn't seem to think it different from #|...|#
> and I didn't want to bother looking down that jar of messy elisp. I'll
> remember youe suggestion, though.
>
Some older version of lisp-mode+cl-indent were mistreating #| ... |#
especially when you had parenthesis inside the comment, i.e., font-
lock was not working properly. Nesting of #| |# was also a problem.
#|| .. ||# partially fixed the problem.
I have not checked whether newer versions work better.
Cheers
--
Marco
On Dec 30, 7:46 pm, Kent M Pitman <······@nhplace.com> wrote:
> verec <·····@mac.com> writes:
> > I have seen many examples using #+nil for this
> > purpose, but this precisely doesn't work for
> > incomplete expressions whereas:
>
> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
> the VAX some years ago), and #+NIL actually did have an implementation
> it was defined in. I don't recommend it for conditionals. #+(or) is
> safer, though not terribly intelligible to everyone. #+ignore is something
> I've seen enough people use that it's unlikely anyone would make :ignore
> feature and expect it to work.
You know, none of this actually matters, because unconditionally
commented-out code should never be released (or even checked into the
code repository).
So all that matters is whether the trick works in your sandbox.
If #+NIL does the job for you from the time you add it, to the time
you remove it before passing the code onto anyone else, then that's
fine.
And we don't need a comment-out shorthand in Lisp, because we don't
need features which specifically don't belong in production code.
Therefore, of course, Scheme needs such a feature. :)
P� Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <········@gmail.com>:
>
> You know, none of this actually matters, because unconditionally
> commented-out code should never be released (or even checked into the
> code repository).
>
> So all that matters is whether the trick works in your sandbox.
>
> If #+NIL does the job for you from the time you add it, to the time
> you remove it before passing the code onto anyone else, then that's
> fine.
>
> And we don't need a comment-out shorthand in Lisp, because we don't
> need features which specifically don't belong in production code.
>
> Therefore, of course, Scheme needs such a feature. :)
If you have ever worked with CVS in a large group you would know this is
nonsense.
The most common cause of CVS update discrepancies is deleted code. Merging
code usually is uneventful, but if someone adds code to a module while
another deletes from it havoc is made. It is much preferable to comment
out code rather than delete it as this only adds two lines of code
(assuming #| and |# on separate lines)
Later before a release is made the CVS repository is locked and a script
(Perl?) is used to remove the code that is commented out. Then all members
delete their local repositories and check out a fresh copy.
--------------
John Thingstad
On Dec 31, 5:10 pm, "John Thingstad" <·······@online.no> wrote:
> På Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <········@gmail.com>:
>
>
>
> > You know, none of this actually matters, because unconditionally
> > commented-out code should never be released (or even checked into the
> > code repository).
>
> > So all that matters is whether the trick works in your sandbox.
>
> > If #+NIL does the job for you from the time you add it, to the time
> > you remove it before passing the code onto anyone else, then that's
> > fine.
>
> > And we don't need a comment-out shorthand in Lisp, because we don't
> > need features which specifically don't belong in production code.
>
> > Therefore, of course, Scheme needs such a feature. :)
>
> If you have ever worked with CVS in a large group you would know this is
> nonsense.
Busted! Yeah, I'm really a janitor pretending to be a software
developer on Usenet.
> The most common cause of CVS update discrepancies is deleted code.
No, that honor probably belongs to the idiotic $ keyword $ expansions,
like $Log$. :)
> Merging
> code usually is uneventful, but if someone adds code to a module while
> another deletes from it havoc is made.
Not havoc, just a conflict. This is correct; there ought to be a
conflict:
<<<<<<<
old version
with
your edits
=======
[ empty: gone in the new copy ]
>>>>>>>
You can't keep around obsolete code just so that the merge algorithm
has a place to patch irrelevant changes.
If I'm modifying code which no longer exists, I want this to be
flagged, ASAP.
It is much preferable to comment
> out code rather than delete it as this only adds two lines of code
> (assuming #| and |# on separate lines)
So now instead of conflict markers, you have a potential bad merge
situation. You're fixing something in some code, do an update, and now
your change is silently commented out.
This is a potential semantic conflict which is not reflected in a text
conflict. It might be a semantic conflict, because the programmer who
commented out the block of code didn't intend to comment out /your/
change, which didn't exist in his copy. If you had won the race and
committed your change first, that programmer might have thought, oops,
I don't want to comment out this new part!
In general, it's when merges /don't/ produce conflicts that you have
to worry. A detected conflict is better than an undetected one.
KK> You know, none of this actually matters, because unconditionally
KK> commented-out code should never be released
so, you say that something like 100% of open source Common Lisp libraries
and implementations should never be released?
bold statement.
to start with:
····@debetch:~/sbcl-1.0.9$ find . -name "*.lisp" | xargs grep "#+nil" |
wc -l
211
or you think commercial software is somehow better? grepping for source code
found in ACL (of cource not ACL's code itself, but examples etc) shows some
76 occurences of #+ignore.
KK> (or even checked into the
KK> code repository).
yes, in theory it works, as well as for hello-world project, maybe.
On Tue, 1 Jan 2008 05:35:10 +0200, "Alex Mizrahi" <········@users.sourceforge.net> wrote:
> KK> You know, none of this actually matters, because
> KK> unconditionally commented-out code should never be released
>
> so, you say that something like 100% of open source Common Lisp
> libraries and implementations should never be released?
>
> bold statement.
So, you're saying that 100% of all open source Common Lisp libraries
contain unconditionally commented-out code?
Bold statement...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 1 Jan 2008 05:35:10 +0200, "Alex Mizrahi" <········@users.sourceforge.net> wrote:
>
>
>> KK> You know, none of this actually matters, because
>> KK> unconditionally commented-out code should never be released
>>
>>so, you say that something like 100% of open source Common Lisp
>>libraries and implementations should never be released?
>>
>>bold statement.
>
>
> So, you're saying that 100% of all open source Common Lisp libraries
> contain unconditionally commented-out code?
>
> Bold statement...
So you're saying "something like 100%" is 100%?
Bold statement...
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Tue, 01 Jan 2008 09:32:28 -0500, Ken Tilton <···········@optonline.net> wrote:
> So you're saying "something like 100%" is 100%?
>
> Bold statement...
Hey, you always need to have the final say, or what?
Tststs...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 01 Jan 2008 09:32:28 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>So you're saying "something like 100%" is 100%?
>>
>>Bold statement...
>
>
> Hey, you always need to have the final say, or what?
Well, since I was looking forward to this thread continuing on for a
dozen more "Bold statements...", the latter.
More interesting is the point that exactly 100% of successful systems
change so any good debugging code used to get them to where they are is
likely to be handy in the future. I would love to hose out all the
debugging statements from Cells, and may someday just because it seems
so stable and the code looks so horrific, but when things do go wrong I
def like being able to uncomment the things quickly.
In my current project I have the same problem in a micro sense,
subsystems sometimes needing debugging, sometimes not. I have one
nonsense feature X42 always pushed, and disable debugging code with
feature #+xxx. When I need that code again, I change the xxx to x42. The
win here is that when I get that issue debugged, I can just search on
x42 and replace with xxx to quickly find and quiesce all the noise.
>
> Tststs...
Confetti in your teeth?
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
??>> so, you say that something like 100% of open source Common Lisp
??>> libraries and implementations should never be released?
??>>
??>> bold statement.
EW> So, you're saying that 100% of all open source Common Lisp libraries
EW> contain unconditionally commented-out code?
EW> Bold statement...
_something like_ 100%. especially if we count (transitively) libraries that
depend on libraries containing unconditionally commented-out code.
for example, out of drakma's dependencies there are at least three libraries
with uncoditionally commented-out code:
cl-base64:
#+ignore
(defmacro def-base64-stream-to-* (output-type)
;;(def-base64-stream-to-* :string)
;;(def-base64-stream-to-* :stream)
cl+ssl:
(t
;; (warn "lisp-ctrl(~A,~A,~A)" cmd larg parg)
0)
usocket:
;;Not in use yet:
;;(defclass datagram-usocket (usocket)
;; ()
;; (:documentation ""))
;; Nameservice errors: mapped to unknown-error
;; (sb-bsd-sockets:no-recovery-error . network-reset-error)
;;(defun print-java-exception (e)
;; (let* ((native-exception (java-exception-cause e)))
;; (print (jcall (jmethod "java.net.BindException" "getMessage")
native-exception))))
imagine all such libraries will magically disapear -- because Kaz says they
"should never be released". how many useful libraries will remain working?
On Tue, 1 Jan 2008 19:10:14 +0200, "Alex Mizrahi" <········@users.sourceforge.net> wrote:
> _something like_ 100%.
Still pretty bold.
> especially if we count (transitively) libraries that depend on
> libraries containing unconditionally commented-out code.
Non sequitur. See below.
> imagine all such libraries will magically disapear -- because Kaz
> says they "should never be released".
He didn't say that. He said:
"unconditionally commented-out code should never be released"
That's definitely not the same. Unless you're talking about libraries
where /all/ of the code is unconditionally commented-out. In that
case they're pretty useless anyway, aren't they. (However, if that's
true for "something like 100%" of the Lisp open source libraries, it
probably explains why nobody except Kenny ever gets anything done with
Lisp.)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 1 Jan 2008 19:10:14 +0200, "Alex Mizrahi" <········@users.sourceforge.net> wrote:
>
>
>>_something like_ 100%.
>
>
> Still pretty bold.
>
>
>>especially if we count (transitively) libraries that depend on
>>libraries containing unconditionally commented-out code.
>
>
> Non sequitur. See below.
>
>
>>imagine all such libraries will magically disapear -- because Kaz
>>says they "should never be released".
>
>
> He didn't say that. He said:
>
> "unconditionally commented-out code should never be released"
>
> That's definitely not the same. Unless you're talking about libraries
> where /all/ of the code is unconditionally commented-out. In that
> case they're pretty useless anyway, aren't they. (However, if that's
> true for "something like 100%" of the Lisp open source libraries, it
> probably explains why nobody except Kenny ever gets anything done with
> Lisp.)
My, oh, my, Dr. Weitz is certainly starting off 2008 with a bang. I
recommend more champagne.
hth,kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
verec <·····@mac.com> writes:
> And then started to wish there was some tutorial somewhere
> that started out by: here's the list of concepts that are
> REALLY different in CL that you must positively master before
> even thinking writing non toy examples...
The concept that is really different is what I call
when-lore.
Having made some progress understanding the when-lore of
Common Lisp I started to write a couple of tutorials, but
gave up before I had got anywhere.
http://www.cawtech.demon.co.uk/lisp/whenlore/tales-from-the-whenlore.html
http://www.cawtech.demon.co.uk/lisp/whenlore/simple-when-lore.html
The most important reason for giving up is the difficulty of
editing work intended to explain stuff that one now
understands. The process of learning requires forgetting the
misconceptions that tripped one up first time around and
this forgetting disqualifies one from writing a tutorial.
So I'm tempted to leave writing such tutorials to academics,
who have a fresh bunch of students each year and can see if
version n+1 communicates more effectively than version n.
If one or two Stakhanovite heroes of socialist labour are
willing to sign up in advance to read my tutorials carefully
and tell me in detail how badly they suck, then I willing to
write them.
I know a priori that version one sucks. If I don't get the
feedback I need to produce an improved version two, then I'm
just left with putting bad tutorials on the web to confuse
newbies and I don't see the point in that.
If you are are interested in helping
http://www.cawtech.demon.co.uk/lisp/symbols-and-packages.html
is half done and in need of criticism.
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> If you are are interested in helping
>
> http://www.cawtech.demon.co.uk/lisp/symbols-and-packages.html
>
> is half done and in need of criticism.
>
Well, one minor thought - I get what you're saying with "hierarchical",
but there might be a tiny opportunity for confusion with the dotted
hierarchical/relative package _naming_
(i.e. "com.example.foo.bar:baz") extension that several lisp
implementations support (as something a bit more than a mere package
naming convention due to meaning attached to relative paths
e.g. "...stuff.impl.x:y")
http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc21
But dunno whether it would be in keeping with the style of the doc to
note that some implementations provide support for hierarchically
structured package naming and that's a separate issue and not at all
what you mean.