|
From: Sam S. <sd...@gn...> - 2004-11-22 20:12:47
|
> * Nicolas Neuss <Avp...@vj...> [2004-11-22 19:28:39 +0100]:
>
> Sam Steingold <sd...@gn...> writes:
>
>>> * Marco Antoniotti <zn...@pf...> [2004-11-22 12:16:18 -0500]:
>>>
>>> This is just a conventional way of doing what you'd do in C/C++ with
>>>
>>> #if 0
>>> blah blah bla
>>> #endif
note that it's
#if 0
not
#ifdef DISABLED
because it is possible someone will process the file with "gcc -DDISABLED"
>>> Do not add NIL to the features. When you see #+nil it usually means
>>> that the code is dead and left around for documentation (grin) purposes.
>>
>> "#+nil" is broken by design.
>> use "#+(or)" instead.
>
> Sadly, it is one character more to type...
no, in Emacs, Shift-9 inserts both the opening and the closing paren.
(so, yes, you do have to hit an extra button, and to consume an extra
8 bits of your preciously scarce disk space, but that is not a big price
to pay for correctness.)
> Citing Dan Barlow from asdf.lisp:
with all due respect to everyone involved, we all sometimes write lousy
code (at least _I_ do, and that makes me think that others sometimes
might too), so the fact that Dan Barlow does it, does not prove that the
trick is valid.
> #+nil (error "The author of this file habitually uses #+nil to comment out
> forms. But don't worry, it was unlikely to work in the New Implementation
> of Lisp anyway")
if your user uses this #+nil trick and then adds NIL to
*features* just to enable some code, you will have a lot of fun
explaining to him why matlisp is suddenly broken.
plain and simply, "#+nil" is a source code bug
(unless you _do_ support the New Implementation of Lisp).
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
If abortion is murder, then oral sex is cannibalism.
|