In article ···@franklin.cc.utas.edu.au, ·····@hilbert.maths.utas.edu.au (spoon) writes:
>I want to be able to output lisp code with comments (produced by the
>compiler).
If I understand correctly, you want the comments to somehow be part of
the *list* structure that implements your code. This is weird (IMHO)
but you could simply define a COMMENT function that is a no-op:
(defun comment (&rest anything) (declare (ignore anything)))
Then the pattern compiler could generate comments using literal
strings, e.g., (comment "This string will be ignored during pattern
matching.").
>... I suppose I could always print the stuff to a file, but it's much easier
> to build the code as a list etc etc.
If you're not (eventually) saving the code in a file then why do you
care about comments?
---
Len Charest, Jr.
JPL Artificial Intelligence Group
·······@underdog.jpl.nasa.gov
"There's no need to fear...Underdog is here!"
In article <··········@lo-fan.jpl.nasa.gov>, ·······@@aig.jpl.nasa.gov (Len
Charest) wrote:
> In article ···@franklin.cc.utas.edu.au, ·····@hilbert.maths.utas.edu.au (spoon) writes:
> >I want to be able to output lisp code with comments (produced by the
> >compiler).
>
> If I understand correctly, you want the comments to somehow be part of
> the *list* structure that implements your code. This is weird (IMHO)
> but you could simply define a COMMENT function that is a no-op:
>
> (defun comment (&rest anything) (declare (ignore anything)))
A better way is to make comment a macro that produces no code, e.g.
(defmacro comment (&rest comments) (declare (ignore comments)) '(progn))
That way you won't have a spurious function call in the event that your
compiler is not very clever.
You can also just put strings in the code, e.g.
(defun foo ()
(do-something)
"This is a comment."
(do-something-else)
...)
I agree this is a weird thing to do.
--
Erann Gat
···@robotics.jpl.nasa.gov
Actually, all three of the answers so far could, in some cases, produce
problems. Then function, the macro [which produces a (progn)], and the
string all have a value which, if it somehow ends up being the last form,
will return.
I don't remember when it was, but early on in my LISP learning, I was
writing a macro that in some cases could have compiled to a no-op. Alas,
there is no true way for a macro to just produce nothing. It was no
problem to make it produce NIL, but that was not quite what I wanted, since
I wanted the macro to come last, but if it was nothing for the previous
statement to be the return value. I hacked something up, but it offended
my esthetics. :-)
I am now wondering if X3J13 [sp?] or Steele or any other LISP compiler
designer have a good reason for not allowing a macro to, um, what
self-destruct?. Or if anyone has designed such a best what is its syntax?
--
--
--
-- "TANSTAAFL" Rich ·····@ils.nwu.edu
The *new* Interlisp way of solving this problem has been in Medley ever
since Interlisp and Common Lisp were merged (back in 1986). Comments are
kept in list structure the same way they always were, but the system
keeps a "source for editing" structure and an "installed for execution"
structure. The latter is generated from the former by stripping the
comments out whenever a change is made.
This, in combination with the new structure editor, makes editing Common
Lisp code in Medley just like editing Common Lisp anywhere else: close your
eyes and type, put comments anywhere you like, and it works. The editor
completely hides the structurizing of comments: when you type
;; This is a comment
the structure editor turns it into
(* |;;| "This is a comment")
but displays what you typed. The number of semi-colons control the
indentation of the comment in the standard way.
--
Internet: ····@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860