Subject: Re: Comments in LISP (was Re: Which one, Lisp or Scheme?)
From: Erik Naggum <erik@naggum.no>
Date: 1997/02/03
Newsgroups: comp.lang.lisp,comp.lang.scheme
Message-ID: <3063966081632362@naggum.no>


* Simon Brooke
| Common LISP assumes that you will edit the file, not the structure.

this is of course untrue.  there are no assumption at all on how or what
you will edit if you want to edit Common Lisp programs.  all the standard
says is that if you put things in a file, and use `read' to convert the
external representation into the internal representation, the semantics of
that operation is well-defined.  editing is certainly outside the scope of
the standard.

| The issue of comments in LISP is of course very difficult, because if
| they are part of the structure they have to evaluate to something, and
| consequently putting comments in the wrong place can affect the
| computation (cf, again, InterLISP, where comments evaluated to NIL).

I find the issue of comments to be simple.  if you need them, you bind the
semicolon and the sharp vertical bar to reader macro functions that return
an object of the appropriate comment type, which also prints as a comment
in the usual syntax.  your codewalkers then need to learn to skip such
objects.  shouldn't be too hard.  if you need to load it as code, after you
have edited it, it should be no harder then to remove comment forms.  the
way I see it, this can be done entirely outside the language.

| Of course this should not happen.  Richard Barbour's (Procyon Common
| LISP) solution of holding the comment structure on the property-list of
| the function symbol was an interesting work-around.  But I feel that the
| solution of treating the comments as things which are entirely lost when
| a function is loaded into core is a cop-out.  It also has very
| unfortunate results for people who write code which manipulates code,
| because all internal documentation gets lost in the process.

I had this problem in SGML a few years back.  it is not a problem as long
as you don't confuse code-as-data and code-as-code.  the conversion is not
trivial to begin with, and a pre-pass to delete unwanted elements is not
really an issue.  the issue is fundamentally the same as retaining white
space in processing many other languages.  in Common Lisp, it's easy to
modify the behavior of the reader.

#\Erik
-- 
1,3,7-trimethylxanthine -- a basic ingredient in quality software.