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

[Steve Yegge]

This is nicely argued.

I've made the mistake of failing to record any information when I've encountered

this specific error category that's been plaguing me.  We've got ~4000 Emacs

users at Google, and there is a core group of 20 or 30 folks who act as tech

support for the rest.  We've got a big net trolling along the bottom of the ocean,

and we catch all sorts of unpleasant stuff, but we're just throwing it back rather

than keeping records.  So I don't have a bunch of bug repro cases, nor specific

code that would have been cleaner had the lower-level functions accepted nil.

The most recent occurrence is relatively fresh:  I was observing some annoying

behavior in a Google elisp library -- one that had been doing some path manipulation

and choking on nil because, for whatever reason, `temporary-file-directory' had

been bound to nil.  So I fixed up the Google function to handle nil the same way

it handles the empty string.  And I glanced around and noticed that the same

hack had been applied all over the place, sometimes smoothed over with macros

or what have you.  It was a lot of smoothing over what appears to be a core wrinkle.

That said, it was just one example, and I have not kept good records -- in part

because most Googlers are still on emacs 23, and I haven't wanted to file bugs

until I can verify them in emacs24, which is more time than I've had to allot to it.

I'm on emacs 24 now, and I'll be dutiful about it, but it's going to be another year

or two at least before I'm able to respond to the demands for specific examples.

But even then it seems unlikely that I'll report the majority of them, because once

people start asking for hundreds of case-by-case justifications, the battle is lost.

That's why I tried arguing it from the general case on the first go-round.

But no matter.  It was a thought experiment.  I've planted a seed, and maybe

in the coming years people will start evaluating any occurrences they may

encounter of errors on nil-valued string args.  In time we may have a corpus of

evidence one way or the other.  If not, I'll eventually have a pile of examples as

I begin keeping better records.

In the meantime, I very much like Stefan's argument to the effect that patches

speak louder than words.  I'll patch my local copy and start playing with it.

I also like his observation that nil-in-nil-out aids function composition.

Unfortunately, given that most of the arguments in this thread are focused on

type assertions, it's unlikely that jumping on that bandwagon will turn the tide.

In the shorter term, I hope to be able to get some concrete bug reports around

emacs 24 startup behavior and/or library-loading behavior over the next few

months, now that more of us are using it.

-steve

On Fri, Apr 27, 2012 at 2:24 PM, Drew Adams <address@hidden> wrote:

> I've decided that throwing errors on nil strings -- however
> good the intentions may have been -- is doing more harm than good.
...

> I'm arguing that for a very specific corner of the type system,
> we merge two separate meanings of nil.  I'm arguing that the
> empty string as it is used today is, for all intents, just
> another nil.  So it should not signal an error if they are
> treated the same.

Just because "" and () are similar in some ways does not mean that they should
be treated as identical in general - any more than [] and () should be.  "For
all intents, just another nil" can apply to a lot of things, including 0 for
whole numbers.  Should we conclude also that throwing errors on nil numbers,
like "nil strings", does more harm than good?

No, you didn't make so general an argument - good.

You limited it to "all the core string-manipulation functions" (not very clear
to me), and even more specifically to "the smallest set of [core?] functions
that may originate the infamous `wrong-type-argument (stringp, nil)' error".

But that still quite general appeal wrt string type errors ("Throwing an error
on a nil string is a radical departure from the core philosophy.") was countered
by pointing out that sometimes it is TRT to raise such an error.

And you yourself said in the same breath that "Emacs libraries should already do
nil-checking on string arguments."  Surely they do, and in some cases they raise
an error as a consequence, and in some cases the only possible or the most
appropriate error is the one being decried.

As long as we discuss this at such a general level your argument will not go
far, I'm afraid.

So you say even more narrowly that there is a well-defined class of cases - a
"corner" where you feel that "" and () should be equated and raising an error is
wrong.  I fear that even this more constrained hand-waving is still unlikely to
cut the mustard, but if you nail it down clearly then maybe you can progress
with it.

If you are convinced that your argument is truly more general than what can be
dealt with case by case, and you can accurately identify the "very specific
corner of the type system" that merits such a change, then, by all means,
identify it rigorously and give supporting arguments.

IOW, be specific about your very specific corner.  Specify the problem and its
boundaries.

Barring that, I'd add my voice to the advice already given by others: handle any
particular functions that you feel ought to treat "" and () the same, but do not
yet do so, on a case-by-case basis.

Start with a specific function where you think it is bad design to distinguish
"" from () and to raise an error when () is encountered but "" was expected
(i.e., acceptable).  For that function, point to a specific problem - e.g. a
startup problem, since you refer to that.

IOW2, give specific arguments for each such function as to why it should equate
"" and ().  IOW3, identify the specific problems you've run into - file a bug,
for instance.

You are much more likely to have others see your light if you are specific and
clear.  In fact, if you had started with a specific bug report, it's quite
possible that others would themselves have made the same leap to your "corner",
assuming it is well-defined.

Finally, you say that the "real reason" for your quest is that if such an error
is raised at startup then a newbie's goose is nuked.  For that, I'm afraid, the
replique given already is the right one: recipe please.  It sounds like you or
someone you know has stumbled on a bug that needs fixing.  And that, I think, is
the place to start.  It is, after all, the real problem behind your real reason.

FWIW, I am sympathetic to the problem you describe.  I even filed a
(non-specific, no-recipe, not-very-useful) bug report a while back that could
perhaps be a poster child for the "worse" scenario you cite:

 "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."

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105

And yes, debugging that one (in particular, but perhaps it is not really so
particular) is not so simple.

But the good news is that I see this particular behavior _only_ in Emacs 24,
which is not yet released.  So your argument about developers vs users, even in
the narrow sense in which it might sometimes be appropriate, does not really
apply here.

The better news will be when the bug can be found and fixed.  But so far at
least I'm not convinced that your proposal is the right way to deal with this
case.  I'd sooner see it found and fixed than finessed.