From ... From: Erik Naggum Subject: Re: Comments, was Re: Parentheses Hierarchy Date: 1999/07/27 Message-ID: <3142044283494830@naggum.no>#1/1 X-Deja-AN: 505669204 References: <379489D3.C4241361@qcunix.qc.edu> <7n4qh9$abh$2@spitting-spider.aracnet.com> <3141970431547512@naggum.no> <3141980284975855 mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Tom Breton | I have never suggested in any way that comments should carry any | additional information. which is the very definition of additional information, since comments carry exactly zero information to the READ function. | I say they should not be lost during mechanical transformation. READ is the wrong function for mechanical transformation of source code, but the right function for mechanical transformation of parsed source code. I really don't see why you keep not getting this distinction. is it because you perchance do not understand what READ does and that Lisp source code is _not_ stored as text? nah, that just _can't_ be. incidentally, speaking of mechanical transformation, one of my pet peeves with Emacs is that M-^ (delete-indentation) does not understand comments. consider ...) ;blargh ))) and try to lift the closing parens up to the preceding line with M-^. it becomes ...) ;blargh))) which is wrong, but if comments are structured objects and we have: ...)))) ;blargh the comment is now at a different location in the tree, and if this was the end of a top-level form, the comment is strictly speaking not part of the top-level form, anymore. somehow, humans don't have a problem with that, which suggests that comments are extrastructural, or floating in the source. in the SGML world, which you're trying to reinvent for Lisp, we had floating elements, too, called "inclusion exceptions". the best way to deal with them was to take them out of the source tree and just remember where they were while hanging them on another tree. this was how they were intended to be used, for things like figures, anchors for indices and hypertext, etc, etc, so it wasn't a problem until somebody wanted to use them to "fix" "broken" DTDs. then we realized what a horrible mistake it was not to say outright that they were not part of the structure. but it would equally be a mistake to require them to be placed elsewhere, with explicit anchor points in the structure, so the general concensus emerged that they should never be used for fixing DTDs, only for extrastructural elements. I think I have to write a book, "Know SGML, Forget SGML", and I wonder if it should have a subtitle like "some unforgettable lessons". #:Erik -- suppose we blasted all politicians into space. would the SETI project find even one of them?