From ... From: Erik Naggum Subject: Re: Comments, was Re: Parentheses Hierarchy Date: 1999/07/26 Message-ID: <3141980284975855@naggum.no>#1/1 X-Deja-AN: 505352699 References: <379489D3.C4241361@qcunix.qc.edu> <7n4qh9$abh$2@spitting-spider.aracnet.com> <3141970431547512@naggum.no> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Tim Bradshaw | I seem to be saying this a lot recently, but anyone who wants to think | about this stuff should have a look at the interlisp-d environment which | did all this. Although it's hard, and perhaps impossible now, you need | to actually spend some time using it, to see where the problems are. | Attempts to do all this from theory will just end up reinventing the same | slightly broken wheel. I would say dealing with comments in SGML and HTML has exactly the same issues associated with them. HTML, for instance, should have made all elements say outright that their contents should be rendered or ignored if not understood. (RTF got that part right, amazingly.) since it doesn't, people had to reinvent the moronic idea of using comments to carry scripts and other meaningful stuff outside HTML proper. they could have used processing instructions, but the morons who wrote HTML browsers couldn't read a specification, so didn't handle it. so now we have a mechanism that requires comments to be read as part of the data, possibly to be interpreted or extracted at a lower layer, just like Tom is proposing for comments in Common Lisp, and it predictably sucks in the same way and for the same reasons that making comments into objects in Lisp predictably sucks. other uses of comments in stupid languages include directives to lint and various compilers, the use of structured comments to embed documentation with code, and ways to carry meta-information where none is otherwise available and then writing processors to deal with the meta-information. is there anything to be learned from this at all, I wonder. if anything, it is that comments should be left alone as a devise for human readers of the code, and should not be processed or even made available to programs that don't expressly deal with human readers of code, such as editors. it is a serious mistake to believe that comments are objects in the code. if you want that, use documentation strings or invent a _proper_ way to annotate your code or data structures or whatnot. bottom line is: if you think using comments is a solution to anything, it can only be because comments are already supported and you think they aren't doing any good, so you can make them do something good, but this is a really, really stupid view, and anyone who makes it learns the hard way that using comments for anything other than communication with human readers of the code is just as stupid as adorning any other feature in the language with an unintended meaning, such as letting variable names carry encoded type information. solve the right problem, don't think you can use whatever you find to kluge up a solution. sometimes, when I read about all these reinvented broken wheels, I think of what incredible genius it took to think up the wheel and what stamina that creator must have had in the face of "helpful" suggestions from his peers. I wonder if it's possible to patent the concept of the broken wheel and sue stupid people for patent infringement. sigh. #:Erik -- suppose we blasted all politicians into space. would the SETI project find even one of them?