> > So, according to the above paragraphs:
> > - The Emacs Lisp end-of-list values are: nil, '(), #f
> > - The Emacs Lisp false values are: nil, '(), #f (same as above)
> > - The Scheme end-of-list values are: '(), nil
> > - The Scheme false values are: #f, nil
> >
> > Because Emacs Lisp code frequently uses the `eq' function to examine
> > list structure, Emacs Lisp's `eq' should treat nil, '(), and #f as
> > identical. Scheme's eq? must be able to distinguish the three.
> --------------------------------------------------
>
>I've always thought of this solution with (eq? nil #f) and
>(eq? nil '()) true. That seems to break less code. You could add a
>special el:nil? (or whatever) function which returns true only for nil.
One problem is that eq? ought to be transitive. It's weird for (eq?
nil #f) and (eq? nil '()) to be true, but not (eq? #f '()).
The other problem with this arrangement is that it's weird for (eq?
nil #f) to be true, but then to have (null? nil) be true and (null?
#f) be false. If things are eq?, they should behave identically.
In the Emacs Lisp world, #f, nil, and '() all act like exactly the
same object. There's no way to distinguish them. So it's consistent
for Emacs Lisp's eq to confound them. However, the Scheme world can
distinguish them, so Scheme's eq? should too.
In my post I tried to make it pretty clear why there is no perfect
solution to this mixture. You can always pick a reasonable set of
assumptions and show they're inconsistent. We're stuck with intuiting
our way towards an approximate solution.