Re: #;
- From: Kent M Pitman <pitman@xxxxxxxxxxx>
- Date: 31 Dec 2007 13:01:28 -0500
"Alex Mizrahi" <udodenko@xxxxxxxxxxxxxxxxxxxxx> writes:
KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
KMP> the VAX some years ago), and #+NIL actually did have an implementation
KMP> it was defined in. I don't recommend it for conditionals. #+(or) is
KMP> safer, though not terribly intelligible to everyone. #+ignore is
KMP> something I've seen enough people use that it's unlikely anyone would
KMP> make :ignore feature and expect it to work.
#+nil is widely used in SBCL implementation source code, so it's unlikely
SBCL can be compiled with NIL :)
Well, first, all Lisp program texts are conforming, and certainly I
would not expect all texts of implementations themselves to be conforming.
On the other hand, it's certainly a reasonable claim that no one is
likely to compile much of anything in NIL. Finding a VAX would be
hard, and I'm not sure if there are emulators. And even if you had
one, I don't know if the NIL sources are available. I offered the
remark about the NIL language per se mostly as color.
Part of my intent, of course, was just inject a bit of history, for fun.
But part of the intent, too, with some marginal practical currency is
that the practice of picking an obscure name and using a #+/#-
conditional with it is error-prone because of the semantics of that.
Over the years, I've seen people more than once end up surprised that
their carefully crafted plan to pick a name no one was using didn't
work. Sometimes it's trivial to dig one's way out of it with some
global editing, sometimes not ... it can depend a lot on how gradually
it happens and how many people are involved in the code. Any shared
namespace has the possibility of name collision.
Note, too, that the failure mode may not simply be "does it not read"
but "why was it put there". For example, some people put these things
on old dead code they don't want to use any more but are afraid to
delete, some people temporarily comment out something that's
troublesome, some people on things that is new code not yet installed.
And sometimes they use different conventions for each of those. And
if others are doing the same thing with different intent, it may
clash. That's why, IF you want to go the route of guessing a name no
one is probably going to use you're going to do this at all, #+BROKEN,
#+OBSOLETE, and #+NOT-YET-TESTED might be more clear than #+NIL.
grepping for #+nil through my libraries collection shows that many popular
libs use it, including SLIME, S-XML, parenscript, Iterate, arnesi.. so one
who pushes NIL into features will break quite a lot of software :)
Just as an aside...
(progn (push nil *features*) :done)
=> :DONE
#+NIL :not :missing
=> :MISSING
[It would have to be :NIL you'd push onto *FEATURES* for that to happen.]
At minimum I wanted to say that #+NIL is not the lispy form of
#ifdef 0
since that NIL is more certainly not the NIL boolean, but rather is a
feature name. That was my point about #+(OR), which really is reliable
because it's primitively defined and cannot be overridden... without
redefining the "#" readmacro of course.
.
- References:
- Prev by Date: Re: Curses alternative for Lisp?
- Next by Date: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
- Previous by thread: Re: #;
- Next by thread: Re: #;
- Index(es):
Relevant Pages
|
