[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: proposal to make null string handling more emacs-y
Date: Fri, 27 Apr 2012 14:24:59 -0700

> 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

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]