From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!news.tu-darmstadt.de!feed.news.nacamar.de!uio.no!nntp.uio.no!ifi.uio.no!not-for-mail From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: Legal ANSI comment form? Date: 24 Aug 2002 04:46:28 +0000 Organization: Naggum Software, Oslo, Norway Lines: 37 Message-ID: <3239153188775738@naggum.no> References: <3D655868.BFE4C243@cs.cmu.edu> <4k7miv7mn.fsf@beta.franz.com> <4elcpk2jp.fsf@beta.franz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: maud.ifi.uio.no 1030164390 4386 129.240.64.16 (24 Aug 2002 04:46:30 GMT) X-Complaints-To: abuse@ifi.uio.no NNTP-Posting-Date: 24 Aug 2002 04:46:30 GMT Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.lisp:38655 * Duane Rettig | Another way to look at it: If I had a CL program and it suddenly broke because | I loaded in a module that pushed :scheme onto the *features* list, then I would | have much less justification for being upset than if I had been using #+ignore | or #+never and someone just stupidly pushed one of these onto *features*. FWIW, I think it is stupid to rely on names out of your control. Since you control a whole bunch of features yourself, there are many ways to ensure that you test for something that you know is there instead of believe will not be there. For the "future" case, you could also use a future version of Allegro CL. Suppose you will never have code for Allegro CL 10.0 while you are working on Allegro CL 6.3 and 7.0 and perhaps 8.0. You could write #+(version>= 10 0) for-further-study to signal to your developers that this is way into the future. You could also use this mechanism to ensure that features were included in a future version despite the cvs branch it was inserted on. Going through the code to find places where a future version were specified would be a good way of ensuring that those future things were indeed brought into the present. Using a feature like debug- would be OK, however, since it would presumably be code that would actually be processed if you requested debugging of that package. This discussion has changed my view on #+ignore and the like. From not having an opinion on it to having an actual opinion on it, I have come to think it is wrong to use /any/ non-existing feature as a marker that some code should not be processed, and in particular that overloading natural language semantics on formal constructs is a form of intellectual sloppiness that should be avoided. -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.