to be at least three weeks. So. Here goes.
I think we should change all the core string-manipulation functions to deal
gracefully with nil arguments. Specifically, I want to change the smallest
set of functions that may originate the infamous "wrong-type-argument
(stringp, nil)" error, making them instead treat nil as if it were the empty string.
By way of justification:
* it's Lispy. Yes, most Lisp dialects got strings wrong, but that shouldn't
stop us. Strings are just character sequences, and whether you like it or
not, the nil/empty-list equivalence is part of Emacs's soul. Throwing an
error on a nil string is a radical departure from the core philosophy.
* wrong-type-argument (stringp, nil) is, anecdotally speaking, both the most
common error encountered by casual users and the most feared, because
it's incredibly difficult to debug. What's so hard about debugging it?
It prevents Emacs from starting up! So your debugger, evaluator, etc. are
all useless, and you're back to binary-partitioning of your .emacs file until you
find the offending code. Setting debug-on-error works for more experienced
users, when it works (which, combined with --debug-init is not very often).
But even then, emacs stack traces are a poor-man's debugging tool at best.
* changing the behavior is unlikely to break much code. Emacs libraries should
already do nil-checking on string arguments. And nobody should be relying
on error conditions for normal control flow, so no code should be depending
on the string functions signaling this error.
The second argument is the real reason I've come to believe we're doing it wrong.
Emacs has amazingly powerful runtime debugging facilities. When Emacs is
running, it's _alive_, and you can help newbies debug problems by sending them
snippets of code to evaluate on the fly.
If Emacs can't start up, or (worse) it gets into one of those horrid scenarios where
some hook is throwing an error on almost every command and preventing the user
from doing anything useful, then you're no longer in Emacs. You're in brokenville.
All the advantages and pleasure of Emacs as a dev environment have vanished.
In a way, I am arguing that Emacs is different from most other software, in that
it is better for Emacs to fail silently and keep running than it is to fail noisily and
prevent the user from doing any work. This is not by any means an argument
you'd make about most software. But over twenty-five years of daily Emacs use,
I've decided that throwing errors on nil strings -- however good the intentions may
have been -- is doing more harm than good.
Before you reject the idea out of hand, I'd like to ask that you consider carefully
what behavior would be most consistent with the rest of Emacs, and would make
best use of existing debugging and diagnostic facilities.
Compared to lexical scoping, this change is pretty minor. ;-)
-steve
p.s. (string= nil "") would still yield nil, of course. I'm proposing that we treat nil
as the empty string, not the other way around.