Many times I and others have had problems with comment lines - if
they get word wrapped, there's an error message.
I have a suggestion to alleviate this problem: make a semicolon a
function, just like the rest of the code:
(; comment blah blah blah
...
...
end of comment)
A closing ;) could indicate end of the comment.
This way it would be simple to comment out a large chunk of code if
desired.
David
--
David R. Sky wrote:
> Many times I and others have had problems with comment lines - if
> they get word wrapped, there's an error message.
>
I use Emacs, which doesn't word-wrap lines in Lisp source buffers.
I take it you don't? How do you code, then?
I certainly hope none of the commercial Lisps word-wrap their source...
On Sun, 12 Dec 2004, Svein Ove Aas wrote:
> I use Emacs, which doesn't word-wrap lines in Lisp source buffers.
>
> I take it you don't? How do you code, then?
> I certainly hope none of the commercial Lisps word-wrap their source...
>
I write Nyquist code on my DOS computer, then run the plug-ins for Audacity
on my Windows machine. I use a screen reader - in DOS, it's immediately
responsive to keyboard commands. The Windows screen reader is v e r r y
s l o w w w in comparison.
I post the plug-ins on the Audacity users group. People who receive the list
in digest mode receive attachments in MIME gibberish, so I also post the
plug-ins in the body of the text. Several people have had problems with the
comment lines. Hence my suggestion.
--
David R. Sky wrote:
> On Sun, 12 Dec 2004, Svein Ove Aas wrote:
>
>> I use Emacs, which doesn't word-wrap lines in Lisp source buffers.
>>
>> I take it you don't? How do you code, then?
>> I certainly hope none of the commercial Lisps word-wrap their source...
>>
> I write Nyquist code on my DOS computer, then run the plug-ins for
> Audacity on my Windows machine. I use a screen reader - in DOS, it's
> immediately
> responsive to keyboard commands. The Windows screen reader is v e r r
> y
> s l o w w w in comparison.
>
> I post the plug-ins on the Audacity users group. People who receive the
> list in digest mode receive attachments in MIME gibberish, so I also post
> the plug-ins in the body of the text. Several people have had problems
> with the comment lines. Hence my suggestion.
>
I see.
Well... there is #| and |#, at least.
On Mon, 13 Dec 2004 09:30:05 +0100, Svein Ove Aas wrote:
> David R. Sky wrote:
>>
>> Several people have had problems
>> with the comment lines. Hence my suggestion.
>>
>
> I see.
>
> Well... there is #| and |#, at least.
Note that Nyquist is written and extended in XLisp, not Common Lisp. I
have no idea whether XLisp supports #|...|# style comments (but I agree
that they are the way to go if it does).
Cheers,
Bill.
David R. Sky wrote:
> On Sun, 12 Dec 2004, Svein Ove Aas wrote:
>
>> I use Emacs, which doesn't word-wrap lines in Lisp source buffers.
>>
>> I take it you don't? How do you code, then?
>> I certainly hope none of the commercial Lisps word-wrap their source...
>>
> I write Nyquist code on my DOS computer, then run the plug-ins for
> Audacity on my Windows machine. I use a screen reader - in DOS, it's
> immediately responsive to keyboard commands. The Windows screen reader
> is v e r r y s l o w w w in comparison.
>
Looking at the Nyquist manual the comments at the beggining
of the plugin (though comments) are actually used.
http://audacity.sourceforge.net/nyquist3.php?lang=
Are these the lines that are wrapped and causing problems?
It seems they have to start with a ;. If they do you will have
to use a non-wrapping editor. I am pretty sure there is a
emacs-like editor for DOS.
Wade
On Sun, 12 Dec 2004 20:35:39 -0800, <···@viper.wapvi.bc.ca> wrote:
> On Sun, 12 Dec 2004, Svein Ove Aas wrote:
>
> I post the plug-ins on the Audacity users group. People who receive the list
> in digest mode receive attachments in MIME gibberish, so I also post the
> plug-ins in the body of the text. Several people have had problems with the
> comment lines. Hence my suggestion.
Then the problem lies in transmittal and not lisp. A script to
cleanup MIME email induced problems seems better aimed at resolving
the problem.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
On Sun, 12 Dec 2004 10:57:57 -0800, "David R. Sky" <···@viper.wapvi.bc.ca> wrote:
> Many times I and others have had problems with comment lines - if
> they get word wrapped, there's an error message.
Looks like you're using the wrong editor... :)
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"David R. Sky" <···@viper.wapvi.bc.ca> writes:
> Many times I and others have had problems with comment lines - if
> they get word wrapped, there's an error message.
>
> I have a suggestion to alleviate this problem: make a semicolon a
> function, just like the rest of the code:
>
> (; comment blah blah blah
> ...
> ...
> end of comment)
>
> A closing ;) could indicate end of the comment.
>
> This way it would be simple to comment out a large chunk of code if
> desired.
Good idea, but wrong idea.
1- a function will try to evaluate its arguments.
2- ; is a reader macro that comments the rest, you'd have to write: (|;| ...)
or to disable the normal ; reader macro.
3- even if you tried to use a macro instead of a function, the reader still
parses the token and try to intern symbols: (|;| toto:titi) will give
errors to the effect that there is no package named toto or no external
symbol named titi in this package.
4- therefore you need a reader macro. There is already one: #| ... |#
5- If your editor font-locks badly this kind of comment you may try to use
strings instead: "...." in places where a string can be evaluated with
no bad consequence.
(defun f1 () ...)
"
This is a comment
"
(defun f2 (x)
"documentation"
(if (null x)
(progn
"this is another comment"
(print "it was empty")
nil)
(progn
"this is a comment too"
(prog1 (cons :not-nil x) ; NOTE without the prog1 the result
"this is a final comment")))) ; would be the comment!!!
Note that even with strings, emacs has problem, when the string span
too many lines, or when it contains parenthesis or braces, foremost in
the first column.
(For comment wrapping, the problem is not editors, it's GUI
news-readers and mailers).
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Hello!
David R. Sky <···@viper.wapvi.bc.ca> wrote:
>I have a suggestion to alleviate this problem: make a semicolon a
>function, just like the rest of the code:
>(; comment blah blah blah
>...
>...
>end of comment)
>A closing ;) could indicate end of the comment.
>This way it would be simple to comment out a large chunk of code if
>desired.
Yuck. What's wrong with #| ... |#?
Kind regards,
Hannah.
(defmacro comment (&rest body))
This lets you comment out a sexp simply by inserting 'comment' after the open
paren.
(comment + 2 2)
Unlike #|(+ 2 2)|#, there is some processing done and it returns nil.
Ed Symanzik wrote:
> (defmacro comment (&rest body))
>
> This lets you comment out a sexp simply by inserting 'comment' after the
> open paren.
>
> (comment + 2 2)
>
> Unlike #|(+ 2 2)|#, there is some processing done and it returns nil.
Since it returns nil, you probably can't use it in places like this:
(let ((foo (comment foo tastes like spam) (make-instance 'spam)))
...)
because then foo would be assigned to nil and some error would probably be
thrown by the let expander. But any place you have a tagbody or progn, it
should be fine. In other words, as long as you're careful.
And it might be a bit misleading to readers of the code, since it looks a
lot like a function or a macro that actually does something. Incidentally,
you'd have the same issue with a "(;" style comment.
So, if you have reader macros in XLisp, you could do a reader macro that
does the right thing, and suffers only from the second issue. Much
preferable, I think.
Chris Capel
Ed,
thanks _very_ much, that is exactly what I was looking for! I guess I didn't
explain clearly,
(defmacro comment (&rest body))
(comment Because I generally use a DOS word processor to do the majority of
my Nyquist coding, I often have the problem of say a ; from line 2 being
appended to the end of line 1, so Nyquist thinks that the first word of line
2 is an unbound function or something like that... your comment macro is a
great time saver! Thanks again
#| And thanks too to everyone else
#| who responded!
#|
#| David)
On Mon, 13 Dec 2004, Ed Symanzik wrote:
> (defmacro comment (&rest body))
>
> This lets you comment out a sexp simply by inserting 'comment' after the open
> paren.
>
> (comment + 2 2)
>
> Unlike #|(+ 2 2)|#, there is some processing done and it returns nil.
>
--
David R. Sky wrote:
> Ed,
>
> thanks _very_ much, that is exactly what I was looking for! I guess I
> didn't explain clearly,
>
> (defmacro comment (&rest body))
Really, that isn't such a good thing.
Perhaps this would be better:
(set-dispatch-macro-character #\# #\!
#'(lambda (stream subchar arg)
(declare (ignore subchar arg))
(let ((*read-suppress* t))
(read stream t nil t))
(values)))
(+ 1 2 #!(* 2 4))
=> 3
Fairly convenient for commenting out a form.
Ed Symanzik <···@msu.edu> writes:
> (+ 1 2 #!(* 2 4))
> => 3
>
> Fairly convenient for commenting out a form.
Fairly silly. why not merely: (+ 1 2 #+(or)(* 2 4)) ?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Pascal Bourguignon wrote:
> Ed Symanzik <···@msu.edu> writes:
>
>>(+ 1 2 #!(* 2 4))
>>=> 3
>>
>>Fairly convenient for commenting out a form.
>
>
> Fairly silly. why not merely: (+ 1 2 #+(or)(* 2 4)) ?
>
I was going to say #+t(* 2 4) but
I figured I should learn to do my own reader macro,
I like the semantics of #! ,
#! sounded more like what David really wanted,
fewer characters to type.
On Wed, 15 Dec 2004, Ed Symanzik wrote:
> I like the semantics of #! ,
> #! sounded more like what David really wanted,
> fewer characters to type.
>
Exactly. Which is why I liked your (defmacro comment ...) code. I'm not
concerned about speed or "correctness". It doesn't interfere with my
plug-ins' operation. :) And when I have to email the plug-ins as part of an
email, other people don't have to worry about correcting ; and #|
placements, which has often happened.
Thanks again
David
Pascal Bourguignon <····@mouse-potato.com> wrote:
+---------------
| Ed Symanzik <···@msu.edu> writes:
| > (+ 1 2 #!(* 2 4))
| > => 3
| > Fairly convenient for commenting out a form.
|
| Fairly silly. why not merely: (+ 1 2 #+(or)(* 2 4)) ?
+---------------
Personally, I find #+(or) for "off" to be very confusing. I much prefer
a consistent use of #-(and) to turn something off [and likewise #+(and)
to enable], since to my way of thinking the "-" corresponds much more
naturally to "off" [and "+" to "on"].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Pascal Bourguignon <····@mouse-potato.com> wrote:
> +---------------
> | Ed Symanzik <···@msu.edu> writes:
> | > (+ 1 2 #!(* 2 4))
> | > => 3
> | > Fairly convenient for commenting out a form.
> |
> | Fairly silly. why not merely: (+ 1 2 #+(or)(* 2 4)) ?
> +---------------
>
> Personally, I find #+(or) for "off" to be very confusing. I much prefer
> a consistent use of #-(and) to turn something off [and likewise #+(and)
> to enable], since to my way of thinking the "-" corresponds much more
> naturally to "off" [and "+" to "on"].
Wouldn't it be better to define a dedicated reader macro for this? A
recent SRFI suggests #; and #n; could allow for commenting out several
forms, so (+ #2; 1 1 1 1) would yield 2.
Pascal
On Wed, 15 Dec 2004 07:42:15 -0800, <···@viper.wapvi.bc.ca> wrote:
>
> (comment Because I generally use a DOS word processor to do the majority of
> #|
> #| David)
Microemacs is available for Dos. There are also extended-DOS versions
of emacs itself.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
"David R. Sky" wrote:
>
> Many times I and others have had problems with comment lines - if
> they get word wrapped, there's an error message.
>
> I have a suggestion to alleviate this problem: make a semicolon a
> function, just like the rest of the code:
>
> (; comment blah blah blah
> ...
> ...
> end of comment)
>
Interlisp comments were like that; (* ...). The structure editor
supported them well:
(* |;| ...)
(* |;;| ...)
(* |;;;| ...)
(* |;;;;| ...)
were displayed as semicolon comments, indented according to standard
conventions for 1-4 semicolons. You could even select the displayed
semicolons and add/delete them and things would reindent in place.
In original Interlisp code (* ...) was just a special function that
didn't evaluate its arguments and returned NIL, so you couldn't put it
just anywhere in your code.
When Interlisp got Common Lisp mixed into it, a code walker was added to
the back end of the editor, so comment forms were removed before handing
code off to the interpreter/compiler.
- Bob
Hello!
Bob Bane <·····@removeme.gst.com> wrote:
>[...]
>Interlisp comments were like that; (* ...). The structure editor
>supported them well:
>(* |;| ...)
>(* |;;| ...)
>(* |;;;| ...)
>(* |;;;;| ...)
>were displayed as semicolon comments, indented according to standard
>conventions for 1-4 semicolons. You could even select the displayed
>semicolons and add/delete them and things would reindent in place.
>In original Interlisp code (* ...) was just a special function that
>didn't evaluate its arguments and returned NIL, so you couldn't put it
>just anywhere in your code.
I.e. something like this?
(defmacro * (&rest foo) (declare (ignore foo)) nil)
>When Interlisp got Common Lisp mixed into it, a code walker was added to
>the back end of the editor, so comment forms were removed before handing
>code off to the interpreter/compiler.
> - Bob
And... How did Interlisp express multiplication of numbers then?
Kind regards,
Hannah.