#; - lisp

This is a discussion on #; - lisp ; &quot;Alex Mizrahi&quot; &lt;udodenko@users.sourceforge.net&gt; writes:
&gt; KMP&gt; Btw, NIL was the New Implementation of Lisp (a lisp implementation for
&gt; KMP&gt; the VAX some years ago), and #+NIL actually did have an implementation
&gt; KMP&gt; it was defined in. I don't ...

Re: #;

"Alex Mizrahi" <udodenko@users.sourceforge.net> 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)
=> ONE

#+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.

Re: #;

On Dec 30, 7:46 pm, Kent M Pitman <pit...@nhplace.com> wrote:
> verec <ve...@mac.com> writes:
> > I have seen many examples using #+nil for this
> > purpose, but this precisely doesn't work for
> > incomplete expressions whereas:
>
> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
> the VAX some years ago), and #+NIL actually did have an implementation
> it was defined in. I don't recommend it for conditionals. #+(or) is
> safer, though not terribly intelligible to everyone. #+ignore is something
> I've seen enough people use that it's unlikely anyone would make :ignore
> feature and expect it to work.

You know, none of this actually matters, because unconditionally
commented-out code should never be released (or even checked into the
code repository).

So all that matters is whether the trick works in your sandbox.

If #+NIL does the job for you from the time you add it, to the time
you remove it before passing the code onto anyone else, then that's
fine.

And we don't need a comment-out shorthand in Lisp, because we don't
need features which specifically don't belong in production code.

Therefore, of course, Scheme needs such a feature.

Re: #;

På Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <kkylheku@gmail.com>:
>
> You know, none of this actually matters, because unconditionally
> commented-out code should never be released (or even checked into the
> code repository).
>
> So all that matters is whether the trick works in your sandbox.
>
> If #+NIL does the job for you from the time you add it, to the time
> you remove it before passing the code onto anyone else, then that's
> fine.
>
> And we don't need a comment-out shorthand in Lisp, because we don't
> need features which specifically don't belong in production code.
>
> Therefore, of course, Scheme needs such a feature.

If you have ever worked with CVS in a large group you would know this is
nonsense.
The most common cause of CVS update discrepancies is deleted code. Merging
code usually is uneventful, but if someone adds code to a module while
another deletes from it havoc is made. It is much preferable to comment
out code rather than delete it as this only adds two lines of code
(assuming #| and |# on separate lines)
Later before a release is made the CVS repository is locked and a script
(Perl?) is used to remove the code that is commented out. Then all members
delete their local repositories and check out a fresh copy.

--------------
John Thingstad

Re: #;

On Dec 31, 5:10 pm, "John Thingstad" <jpth...@online.no> wrote:
> På Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <kkylh...@gmail.com>:
>
>
>
> > You know, none of this actually matters, because unconditionally
> > commented-out code should never be released (or even checked into the
> > code repository).
>
> > So all that matters is whether the trick works in your sandbox.
>
> > If #+NIL does the job for you from the time you add it, to the time
> > you remove it before passing the code onto anyone else, then that's
> > fine.
>
> > And we don't need a comment-out shorthand in Lisp, because we don't
> > need features which specifically don't belong in production code.
>
> > Therefore, of course, Scheme needs such a feature.
>
> If you have ever worked with CVS in a large group you would know this is
> nonsense.

Busted! Yeah, I'm really a janitor pretending to be a software
developer on Usenet.
> The most common cause of CVS update discrepancies is deleted code.

No, that honor probably belongs to the idiotic $ keyword $ expansions,
like $Log$.
> Merging
> code usually is uneventful, but if someone adds code to a module while
> another deletes from it havoc is made.

Not havoc, just a conflict. This is correct; there ought to be a
conflict:

<<<<<<<
old version
with
your edits
=======
[ empty: gone in the new copy ]
>>>>>>>

You can't keep around obsolete code just so that the merge algorithm
has a place to patch irrelevant changes.

If I'm modifying code which no longer exists, I want this to be
flagged, ASAP.

It is much preferable to comment
> out code rather than delete it as this only adds two lines of code
> (assuming #| and |# on separate lines)

So now instead of conflict markers, you have a potential bad merge
situation. You're fixing something in some code, do an update, and now
your change is silently commented out.

This is a potential semantic conflict which is not reflected in a text
conflict. It might be a semantic conflict, because the programmer who
commented out the block of code didn't intend to comment out /your/
change, which didn't exist in his copy. If you had won the race and
committed your change first, that programmer might have thought, oops,
I don't want to comment out this new part!

In general, it's when merges /don't/ produce conflicts that you have
to worry. A detected conflict is better than an undetected one.

Re: #;

KK> You know, none of this actually matters, because unconditionally
KK> commented-out code should never be released

so, you say that something like 100% of open source Common Lisp libraries
and implementations should never be released?
bold statement.

or you think commercial software is somehow better? grepping for source code
found in ACL (of cource not ACL's code itself, but examples etc) shows some
76 occurences of #+ignore.

KK> (or even checked into the
KK> code repository).

yes, in theory it works, as well as for hello-world project, maybe.

Re: #;

Kent M Pitman <pitman@nhplace.com> wrote:
+---------------
| 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...
+---------------

And I just want to repeat that I still prefer the equally-safe
#-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
since the cognitive dissonance of the former pair is less.
With AND, minus is "off" and plus is "on". Easy to remember.

Re: #;

On Tue, 1 Jan 2008 05:35:10 +0200, "Alex Mizrahi" <udodenko@users.sourceforge.net> wrote:
> KK> You know, none of this actually matters, because
> KK> unconditionally commented-out code should never be released
>
> so, you say that something like 100% of open source Common Lisp
> libraries and implementations should never be released?
>
> bold statement.

So, you're saying that 100% of all open source Common Lisp libraries
contain unconditionally commented-out code?

Re: #;

Rob Warnock wrote:
> Kent M Pitman <pitman@nhplace.com> wrote:
> +---------------
> | 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...
> +---------------
>
> And I just want to repeat that I still prefer the equally-safe
> #-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
> since the cognitive dissonance of the former pair is less.
> With AND, minus is "off" and plus is "on". Easy to remember.

As far as I can tell, #-(AND) is underspecified in ANSI CL.

Section 24.1.2.1 in the HyperSpec is actually not very precise about
'and and 'or feature expressions - it doesn't say that they are related
to the 'and and 'or macros, and it doesn't clearly say what happens when
there are no arguments.

In the case of 'and feature expressions, it says: "An and feature
expression succeeds if all of its argument feature-conditionals succeed;
otherwise, it fails." So does (AND) succeed or fail? How many of its
arguments succeed? All or none?

Same problem for 'or feature expressions, as far as I can tell.

I'd strongly prefer #; because I wouldn't have to spend any time at all
thinking about what it actually means. (In my own code, I actually use
#| |# pairs for the same reason.)