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

[Stefan Monnier]

> compile time.  When you're running the byte compiler or the unit tests, you
> want it to fail loudly and early.  But when you ship the software, and it's
> in the hands of end-users who may not be able to debug it, then unless
> it's running a nuclear reactor or an airplane, you want the software to be
> robust.

Most of the time throwing an `error' doesn't prevent the user from
getting his job done.  E.g. it doesn't "crash" Emacs.  And while the
user may not be able to debug it himself, he is able to get a backtrace
and send it to us, whereas with a more permissive semantics, you don't
get anything, so fixing the problem will require more interactions with
the user.

IOW, I think the problem is when an error makes Emacs unusable, and we
should focus on this (which is typically an issue that's not dependent
on the kind of error signaled, but the context where it's signaled).

> With that in mind, I'm really wondering what the big fear is here.

I have no big fear about your proposal.  I expect it won't make
much difference.

> I don't see any of these creating world-ending bugs, contrary to
> predictions.

I don't expect any change you suggested would bring a significant number
of bugs.  The only downside I mention is that it might hide some bugs
(which would have existed regardless of that change) and make them more
difficult to track down and fix.
Of course, maybe it will also fix some bugs.   And maybe it will also
allow us to simplify some Lisp code.

I general I like the idea of treating lists and vectors uniformly, and
strings are one particular kind of vector.  But Emacs is a conservative
system, so changes have to go slow.  Send us a patch that covers the
most obviously beneficial cases (ideally with some code cleanup made
possible by the new semantics),


        Stefan