This implies that the current return value is not meaningful, a premise
  with which I simply disagree.  Although it would be nice if when and
  unless were defined that way, I think it should be possible to return a
  value from these forms, just that it needs to be a judicious choice.

   (when (find long-sought-thing input-stuff)
      <stuff to do>)

hatefully inferior readability-wise to a double-negative? You can read
double-negatives?! Tell your programmers you just failed the Turing
Test.

Seriously, I think NIL as false is Deeply Correct. Consider FIND. Your
position is that (find x y) returns two possible values, x or nil. Too
literal. FIND either finds x or it does not.

  I find it conceptually very clean.  I find it equally conceptually clean
  that 0 is false in C.  Neither do I have any problems with Perl's false
  values.  I do have a problem with Scheme's anal-retentive false, because
  it is so goddamn hard to obtain a false.

| I don't even see any good reason why NIL should be false.

  There has to be at least one false value.  Making the empty list false is
  simply a very good choice for a language that gives you lists as a close
  to primitive type.  Linked lists have to be terminated by _something_,
  and that something might as well be the answer to the question: "Are
  there any more elements?" as a matter of pragmatics.

| So, I guess what I'm saying is that you ought to explain your objection
| here (or point to a message where you've explained it before, since I'm
| sure you have).

  I have lost track of which objection you might be referring to here, but
  I hazard a guess it is that I think making nil different from false is
  nuts.  It is nuts from a pragmatic point of view.  Conceptualizations
  that go against the pragmatic are even more wrong than Scheme in general,
  but it is precisely because Scheme's conceptulization is impractical that
  they have chosen to make their language impractical but conceptually
  pure.  I think Scheme is an excellent example of how you go wrong when
  you decide that "practicality" is a worthless axis to find a reasonable
  position on, or not even consider at all.  Common Lisp is a practical
  language and its conceptualization is one of trying to figure out what
  the most elegant practical expression would be, not how impractical the
  most elegant expression would be.  This is just something Scheme freaks
  will never accept as a point of serious difference between Common Lisp
  and Scheme.  I look at Scheme from a Common Lisp viewpoint, of course,
  and that is not very productive, but Dorai Sitaram brought up this Scheme
  nonsense as a reasonable way to talk about Common Lisp features.  I think
  I put it sufficiently clear when I started my reply with "Scheme is all
  wrong".  Those who do not think so are of course free to talk about
  Scheme all they want, but the sheer _insistency_ that Scheme freaks come
  to present their "views" about Common Lisp is really annoying.  At least
  they have their own community, so it is not as if they are fragmenting
  the _Common_ Lisp community, but they also think they have a Lisp, and
  that is at least as annoying.

  Yes.  Adding (not (null ...)) to previously obvious code would make
  everything nearly unreadable.  Besides, the intention _is_ to return the
  empty list to those who look for a list and false to those who want a
  boolean value.  This is an important property of Common Lisp.  Scheme
  does not have this property, and consequently Scheme systems have a
  gazillion small functions that are anal-retentively type-specific.  One
  of the reasons I like Common Lisp is that it has none of this nonsense.

[ As for Perl, you really don't mind the *string* "0" being false?!?! ]

But, yes, my first reaction to your code above is that FIND returns a
boolean.  Really, it returns a list.  So the body of your WHEN is
being run when FIND returns a non-empty list, not when it returns
true.  Imagine recasting it numerically:

  (when (not (zerop (count long-sought-thing input-stuff)))
     (do-stuff))

if that had been:

  (when (count long-sought-thing input-stuff)
     (do-stuff))

you would assume that COUNT was a predicate.

None of this causes me much of a headache, though, and it's usually a
difference of a half a second or less to figure out that someone meant
false, not ().

And, so there's no misunderstanding, I don't mean to rehash this in
any sort of Common-Lisp-is-broken-because... or The Next Standard
Should Do... sort of way.  I just don't think it's nutty to
distinguish NIL, (), and flase.

  % perl -wle '$a="cond"; sub f { unless ($a) {"cons"} }; print f'
  cond
  % perl -wle 'sub f { ($a="cond", "cons") until $a }; print f'
  cond

(please don't answer that- it's a rhetorical question :)

  Nonono, you are just _wrong_.  :)

| And, honestly, I don't see anything about #F as different from () and NIL
| that would make it hard to get, per se.

  It would mean that functions need to know whether they should return an
  empty list or a boolean.  This is the reason that the pun is useful, just
  as 0 being false in C is useful.  I actually find s specific boolean type
  to be incredibly painful -- to use it, you would always need multiple
  values.  It is not unlike asking real people "Do you know the time?".
  "Yes" is not a good answer.  Just the time will do nicely, thank you.  If
  you had me test for, say, find returning true before I could use its
  return value, I would probably write macros to circumvent such nonsense.

| [ As for Perl, you really don't mind the *string* "0" being false?!?! ]

  That Perl does type conversions east and west so you never actually know
  what type of object you are dealing with is sometimes convenient par
  excellence, but most of the time, it is just plain nuts.  However, it is
  actually useful in a number of languages.  SQL, for instance, gets around
  some of its syntax problems with this flexibility.

| Actually, I meant NIL qua symbol, not the empty list.  Although, if I had
| my druthers, () wouldn't be false either.  I just don't see what's so
| hard about writing (not (null ...)).

  Well, it looks like really bad language design.  Like Scheme.  Failing to
  have a function that turns something into a boolean directly is bad.  If
  you want to see if foo is a non-empty list, (not (null foo)) looks dumb,
  but if you are expecting a list, (consp foo) is the right choice, in
  which case you are well advised to look at typecase instead of cond.

| While I won't argue with that characterization of Scheme, I don't think
| that seperating () and false is choosing purity over practicality.

  Well, conflating "nothing" and "false" has long traditions in both logic
  and programming languages.  I think objection to it come only from a
  misguided sense of purity without a sense of history or continuity.

| I think it's easier to read code that checks for NIL explicitly, and I
| don't think that checking with the NULL predicate is a particular
| hinderance.

  Well, if you used typecase and tested for null and cons and other types,
  I would probably support you, but (not (null ...)) says "Scheme freak!"
  to me, and in a horrible font, too.  :)

(setf foo (when (valid? bar) (blah)))  ; Using implicit NIL as valid return

But I'd have no problems with

(setf foo (if (valid? bar)
              (blah)
              nil))

I only use WHEN and UNLESS in things like

(unless (valid? bar)
   (error 'invalid-bar-error))

To each his own, I guess...

I'm very careful about their use.  Thus

(let ((bar '())
      (baz nil))
  ;; Here I fully expect BAR to be used as a list,
  ;; and BAZ as an atom.
  ...)

What's more, I used NOT to make that distinction.  It's only with
some years of practise (i.e. with _expertise_, to use your word)
that I've discovered that that distinction matters.

YMMV, of course.

  That depends on how you use it.  I prefer (/= 0 ...) to duoble predicates.

| But, yes, my first reaction to your code above is that FIND returns a
| boolean.  Really, it returns a list.

  But find _does_ return nil or the object you asked it to find.  It does
  _not_ return a list, because it _cannot_ return a cons unless you have
  asked it to find a cons, which is a statement about the specific call,
  not about the function in general.  (Functions like this that return nil
  or cons are member and assoc.)  The function position also returns nil or
  the position where it found something, not a cons, so its notion of true
  is simply "non-nil".

  I maintain that it would not make sense to make nil or () not be false
  without making every other object also not be true.  If punning on false
  is bad, punning on true is also bad.  If we have a pure boolean type, we
  would need to rethink this whole return value business and consider pure
  predicates, not just for things like null to see if a list is empty, but
  it would also be wrong to give it a non-list.  So this is not a question
  just of (not (null ...)), but of (and (listp ...) (not (null ...))),
  which is again what (consp ...) does more efficiently, so the whole (not
  (null ...)) thing is kind of moot.  It works today _because_ of the pun
  on true and false.  It would not make sense to use null on non-lists in a
  strict boolean-type universe, because boolean would not be the only type
  to be treated anal-retentively.

| So the body of your WHEN is being run when FIND returns a non-empty list,
| not when it returns true.

  I think you should look up what find does and returns, now...

| Imagine recasting it numerically:
|
|   (when (not (zerop (count long-sought-thing input-stuff)))
|      (do-stuff))
|
| if that had been:
|
|   (when (count long-sought-thing input-stuff)
|      (do-stuff))
|
| you would assume that COUNT was a predicate.

  But this carefully elides the context in which nil = () = false makes
  sense.  In a language where you return pointers or indices into vectors,
  0 = NULL = false makes sense.  In such a language, you could not have a
  function position that returned the position where it found something,
  because 0 would

| No, my position is that there's a conceptual difference between the empty
| list (), and the boolean false NIL.  And that it's kinda weird that false
| is a symbol.

  Since there _is_ no "false" concept as such, but rather "nothing" vs
  "thing" that supports a _generalized false_, I think the conclusion only
  follows because you think the type boolean is defined differently than it
  is.  In fact, the boolean type is defined as the symbols t and nil.
  (Please look it up in the standard.)

| None of this causes me much of a headache, though, and it's usually a
| difference of a half a second or less to figure out that someone meant
| false, not ().

  I think this betrays a conceptual confusion.  If you realized that they
  are in fact exactly the same thing, you would not need to think about it,
  but since you think they are something they are not, it takes think time
  to undo the confusion.  It is much smarter to fix the confusion at its
  core and realize that you you cannot get what you want because what you
  want is not within the tradition that produced Common Lisp.

  Whew!  You had me nervous there for a second.

 (if (not <test>)
     'no
     <50 lines of code>)

After we come to agreement on this let's go over to comp.lang.c and get
everyone agree on where to put {}s. :)

  (defun foo (list bar)
    (if (not (null list))
        (do-something #'foo list bar)
        (let ((qux ...))
          (do-the-rest-of-the-function))))

Maybe other people's coding style involves cases where this test would
come up more often?  I don't know.  Or, maybe it's because I learned
Scheme first.  Ah, well, surviving habits from scheme, maybe, but not
freakiness.

 [...]

I sometimes write
  (let ((foo (when bar ....)))
      ...

instead of (if bar (progn ....) nil)

abe

Don't forget, folks, we are engaged in hand-to-hand combat with
compilers. Acknowledge their states of mind or perish. I remember
reading about SmallTalk that it had no pointers. Chya. So tell me (mr
author) is copy deep or shallow? Oops.

It would be great if some 3GL let us forget about assembly language, but
in fact every time I want to whack something from a list I must choose
between delete and remove. Explain to bubba that delete and remove from
lists are different...no way, you have to talk about implementation,
cons cells, pointers.

Now to be fair, by saying NIL and '() you are over-specifying, latching
onto conceptual differences at a finer granularity than the compiler, so
you are on solid ground. But to me that attitude is dangerous. It relies
on a fiction. Better to acknowledge the mindset of the compiler, who in
the end decides the behavior of our so-called high-level code.

[(defun d2x/dt2 (x xdot y ydot time)
   ...)]

... but it has still once or twice gotten me to say "Aaargh" :-)

Cheers,

--
Janis Dzerins

Oy, I really didn't mean to draw this out into a long thread.  I
*really* just wanted to refute the idea that it was nuts to separate
NIL and false.  For all the arguments in that direction, the obvious
usability of Common Lisp means that it's also reasonable to conflate
them, despite any conceptual messiness that might (or might not)
entail.  I kept responding because I felt like I needed to clarify
myself.  And then, here we are with a long thread that should've been
3 messages long.  (sigh).  So, this is my last post to this thread,
and not just because I'm about to be away from home for a few days
:-).  It should have died already, and I think it's my fault it
hasn't.  On that note, here are some nice words from R. Kelly, having
nothing to do with Lisp, (), NIL, false, nor Scheme:

"I don't see nothing wrong
 [...]
this is going on 'til the early morn'
and my word is bond."

But anyway, what was more interesting was to look at what I did with
NOT and NULL and conditionals.  I have never thought about this until
I read through code, and I still don't understand why I write what I
do.  For instance why this:

(when (not x) ...)

instead of

(unless x ...)

-- I use both, and they have different meanings to me (not to CL).
Not to mention (NOT (NULL ...)):

(when (not (null x)) ...)
(unless (null x) ...)

-- I have both these too, why?  They have different connotations to
me, but I'm not sure why.  Sometimes I can look back through CVS logs
and catch myself changing one into the other.  And back again.

Regs, Pierre.

  Is there no difference between (- x) and (1+ (lognot x)), either?
  How about (first x) and (car x)?  Or (ash x 3) and (* x 8)?

| Don't forget, folks, we are engaged in hand-to-hand combat with compilers.

  I have never viewed compilers this way.  Compilers are not the IRS.

| It would be great if some 3GL let us forget about assembly language, but
| in fact every time I want to whack something from a list I must choose
| between delete and remove. Explain to bubba that delete and remove from
| lists are different...no way, you have to talk about implementation, cons
| cells, pointers.

  Huh?  (let ((x '(1 2 3))) (delete 2 x) (equal x '(1 2 3))) => nil while
  (let ((x '(1 2 3))) (remove 2 x) (equal x '(1 2 3))) => t.

| Now to be fair, by saying NIL and '() you are over-specifying, latching
| onto conceptual differences at a finer granularity than the compiler, so
| you are on solid ground. But to me that attitude is dangerous. It relies
| on a fiction. Better to acknowledge the mindset of the compiler, who in
| the end decides the behavior of our so-called high-level code.

  Some of us think the specification for the compiler decides the behavior
  of the compiler.  That some things which produce the same effect but look
  different should be treated differently can be exemplified by "its" and
  "it's" and by "there" and "their" and "they're", both of which for some
  reason do not appear to be distinct to a number of American spellers.