Subject: Re: Comments in LISP (was Re: Which one, Lisp or Scheme?) From: Erik Naggum <email@example.com> Date: 1997/02/03 Newsgroups: comp.lang.lisp,comp.lang.scheme Message-ID: <firstname.lastname@example.org> * 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.