Re: proposal to make null string handling more emacs-y

[Eli Barzilay <eli@barzilay.org>]

Four hours ago, Richard Stallman wrote:
>     As a (semi-fake) "Schemer", I can say that it's perfectly fine in
>     practice too.  It catches real errors.  In analogy to what you wrote a
>     few seconds later -- it catches errors that would otherwise get
>     papered over.
> 
> The benefit of making () and false the same in Lisp is NOT a matter
> of suppressing errors.

Sure it is.  (null? (< 1 2)) makes no semantic sense, and you get an
error.  In other lisps, (null (< 1 2)) makes no sense but instead of
an error you get a convention of preferring `not'.  The error that
Scheme throws is suppressed, but using `null' like that is likely to
be an error.  (BTW, Scheme itself is doing the same when it treats any
non-#f value as true.  CLers would also argue that Scheme is also
doing it when it treats identifiers in function positions the same as
elsewhere.)


> The benefit is that we can simplify programs by knowing that () and
> false are the same.

Right, and you get more of these benefits if it's also the same as ""
and as 0, and there are additional benefits in the same direction:
allow using `nil' as a function (that returns `nil' when called),
allow adding numbers, strings, lists, etc with implicit coercions,
maybe allow using numbers and lists as functions (as in arc), and
allow referring to undefined variables and calling undefined
functions.

Each of these simplifies (and shortens) existing code, since they each
encapsulate common code pattern.  But each of these suppresses more
bugs since more defective code runs to completion, returning bogus
results instead of throwing an error.  (I'm talking about defective in
the sense of diverging from what the code should do, not in a
technical execution sense where they're no longer bugs.)

Note in particular that all of these are directly contributing to
Steve's proposal: they lead to less frustraing errors, since more code
will run without exceptions, implicitly doing something that likely
should be done in today's elisp.  Note also his reference to running
code in a browser, where JS is a language that is very intentionally
doing its best to continue running, with modern browsers going farther
by not even showing most people errors.

Arguing that some of these things are better or worse is wrong.  It
doesn't make sense to reject unifying "" and `nil' on one hand and
reject separating false and '() on the other -- *unless* it's clear
that it's a subjective decision.  They are very clearly tradeoffs of
convenience vs robustness.

So the argument is not "scheme is wrong to distinguish false from nil,
elisp is right to distinguish the empty string from nil".  Instead, it
should be an argument about the decision that most elispers do, and
finding the right place on the line.


> Equating () and "" might perhaps give some benefit of simplifying
> programs.  You could try looking for places where you could take
> advantage of that, to see how much convenience it gives.  But this
> is a different matter from avoiding errors.

(Avoiding errors is what started this thread...)


> I tend to think the benefit won't be big, but you can try to show
> I'm wrong.

(I'm making a meta point about the argument, I don't have any
preference for either side.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!