On Sun, 2008-07-13 at 20:36 -0500, Rob Warnock wrote:
> p.s. O.k., confession time: Even more recently I've started getting
> a bit lazy and using "#-+" to enable and "#+-" to comment out.
> My mnemonic is that "#-+" represents a "rising edge", that is,
> goes "from off to on" (enables), while the "falling edge" "#+-"
> goes "from on to off" (*dis*ables). Yes, it depends upon
> (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
> really, *really* unlikely to be violated.
Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
Seems even twice as likely, since it depends on two, not one, unlikely
feature not being present... and #+NIL / #-NIL is more intuitive than
any of alternatives.
--
-><- This signature intentionally left blank. -><-
Maciek Pasternacki <·····@zenbe.com> wrote:
> Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
Remember that NIL (New Implementation of Lisp) was actually Lisp system
-- and one of the inspirations for Common Lisp. Presumably, NIL indeed
did put :NIL in *FEATURES*.
Note that NIL (as opposed to :NIL) is not likely to be an element of
*FEATURES*, even on NIL, and it is still a symbol. Of course, #+ and #-
bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
NIL as (), so...
* (push :nil *features*)
(:NIL :MDW :ASDF ...)
* #+nil t #-nil nil
T
* #+() t #-() nil
NIL
Alternatively, :T is also unlikely to be on *FEATURES*, since T is/was
an dialect/implementation of Scheme. Therefore, #+t may be considered a
safe way of omitting the next S-expression.
Objectionable, no? ;-)
-- [mdw]
On Jul 14, 2:37 pm, Mark Wooding <····@distorted.org.uk> wrote:
> Maciek Pasternacki <·····@zenbe.com> wrote:
> > Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
>
> Remember that NIL (New Implementation of Lisp) was actually Lisp system
> -- and one of the inspirations for Common Lisp. Presumably, NIL indeed
> did put :NIL in *FEATURES*.
>
> Note that NIL (as opposed to :NIL) is not likely to be an element of
> *FEATURES*, even on NIL, and it is still a symbol. Of course, #+ and #-
> bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
> NIL as (), so...
Your thinking is completely backwards here. NIL already names a pre-
Common MACLISP successor. The name is taken, meaning you should be no
more likely to find a future Common Lisp implementation that calls
itself NIL than INTERLISP, MACLISP or LISP 1.5. I'm pretty sure your
code demends on at least CLTL if not ANSI Common Lisp, so it's not
going to run out of the box on NIL anyhow.
> Alternatively, :T is also unlikely to be on *FEATURES*, since T is/was
> an dialect/implementation of Scheme. Therefore, #+t may be considered a
> safe way of omitting the next S-expression.
>
> Objectionable, no? ;-)
Yes :-)
On Mon, 14 Jul 2008 08:47:53 -0700 (PDT), "Thomas F. Burdick" <········@gmail.com> said:
| On Jul 14, 2:37�pm, Mark Wooding <····@distorted.org.uk> wrote:
|| Maciek Pasternacki <·····@zenbe.com> wrote:
|| > Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
||
|| Remember that NIL (New Implementation of Lisp) was actually Lisp system
|| -- and one of the inspirations for Common Lisp. �Presumably, NIL indeed
|| did put :NIL in *FEATURES*.
||
|| Note that NIL (as opposed to :NIL) is not likely to be an element of
|| *FEATURES*, even on NIL, and it is still a symbol. �Of course, #+ and #-
|| bind *PACKAGE* to the KEYWORD package (2.4.8.17), but you can still type
|| NIL as (), so...
| Your thinking is completely backwards here. NIL already names a pre-
| Common MACLISP successor. The name is taken, meaning you should be no
| more likely to find a future Common Lisp implementation that calls
| itself NIL than INTERLISP, MACLISP or LISP 1.5. I'm pretty sure your
| code demends on at least CLTL if not ANSI Common Lisp, so it's not
| going to run out of the box on NIL anyhow.
Nil novum sub soli (pun intended): see
<http://groups.google.com/group/comp.lang.lisp/msg/841ab3ac2a9d5846>,
(especially the two paragraphs starting with "But part of the intent").
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
On Mon, 14 Jul 2008 11:24:59 +0200, Maciek Pasternacki <·····@zenbe.com> said:
| On Sun, 2008-07-13 at 20:36 -0500, Rob Warnock wrote:
|| ...
|| Yes, it depends upon
|| (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
|| really, *really* unlikely to be violated.
| Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
Here is one reason why `#+NIL' is more fragile than `#+-': consider
how this innocently-looking code,
(pushnew (intern (string feature) :keyword) *features*)
would lose if FEATURE is NIL (say, because of an initialization
bug).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Kaz Kylheku
Subject: Re: some corrections Re: The Fundamental Problems of Lisp
Date:
Message-ID: <20080714175913.711@gmail.com>
On 2008-07-14, Maciek Pasternacki <·····@zenbe.com> wrote:
> On Sun, 2008-07-13 at 20:36 -0500, Rob Warnock wrote:
>> p.s. O.k., confession time: Even more recently I've started getting
>> a bit lazy and using "#-+" to enable and "#+-" to comment out.
>> My mnemonic is that "#-+" represents a "rising edge", that is,
>> goes "from off to on" (enables), while the "falling edge" "#+-"
>> goes "from on to off" (*dis*ables). Yes, it depends upon
>> (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
>> really, *really* unlikely to be violated.
>
> Is it any less likely than (MEMBER :NIL *FEATURES*) not being NIL?
> Seems even twice as likely, since it depends on two, not one, unlikely
> feature not being present... and #+NIL / #-NIL is more intuitive than
> any of alternatives.
There are two nice ways to exclude EXPR:
#+(or) EXPR
#-(and) EXPR
The virtue is that these are not hinged to the presence or absence of
any symbol in *FEATURES*.