From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Yegge Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Fri, 27 Apr 2012 21:43:12 -0700 Message-ID: References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <83zk9xheam.fsf@gnu.org> <93BCB9FDF9D2443988F559AD4BEC4DBD@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf30563e47cd6fc804beb5dbe0 X-Trace: dough.gmane.org 1335588217 31083 80.91.229.3 (28 Apr 2012 04:43:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Apr 2012 04:43:37 +0000 (UTC) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 28 06:43:36 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SNzVO-0001RP-Hd for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 06:43:34 +0200 Original-Received: from localhost ([::1]:44980 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNzVN-0002fx-SR for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 00:43:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNzVJ-0002fq-HN for emacs-devel@gnu.org; Sat, 28 Apr 2012 00:43:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNzVG-0008LU-I0 for emacs-devel@gnu.org; Sat, 28 Apr 2012 00:43:29 -0400 Original-Received: from mail-yw0-f52.google.com ([209.85.213.52]:51590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNzV7-0008KE-58; Sat, 28 Apr 2012 00:43:17 -0400 Original-Received: by yhpp61 with SMTP id p61so1171360yhp.39 for ; Fri, 27 Apr 2012 21:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lgW6KURKBBQaNmNB4kG6GVPzYgUlr+PQ5Td5ts85xnU=; b=yj4YKmD9VBpUSAFCTJYwEZKnnyFrvlx9hWlE3NTDOq8zPHKvjI49cTTJTolCyEY5nT Sj1A1cwNqEzlCps7Kku2/rMsTIZognD5OYLFfLUd7JkzZP34WdsUVu0RBOYnFrEHC2/A H7z5o2nlfktsBNvBe4gBbsDfcxcFY7Oa0oLnhos5K1Pc4UTt6oEJIqsNq7jTyLuR4kbg p+OBqmOCx0HLeaek1EMWK94u7L01CBTi9dYm+IyS8JgKxUDjPNJAdR+T2TNz1Wm6TRbV Q4FHoMKoyVUuiYjNoJ1PxQYoBH0P9pdj/b7uJtIPpq0ZyLe+qr0PgcK8wz/0bHzz8T8p MsNg== Original-Received: by 10.236.190.196 with SMTP id e44mr5996463yhn.67.1335588192874; Fri, 27 Apr 2012 21:43:12 -0700 (PDT) Original-Received: by 10.236.156.72 with HTTP; Fri, 27 Apr 2012 21:43:12 -0700 (PDT) In-Reply-To: <93BCB9FDF9D2443988F559AD4BEC4DBD@us.oracle.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.52 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150107 Archived-At: --20cf30563e47cd6fc804beb5dbe0 Content-Type: text/plain; charset=ISO-8859-1 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 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. > > --20cf30563e47cd6fc804beb5dbe0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is nicely argued.

I've made the mistake of fa= iling to record any information when I've encountered
this specific error category that's been plaguing me. =A0We'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. =A0We've got a big net trolling along the bottom = of the ocean,
and we catch all sorts of unp= leasant stuff, but we're just throwing it back rather
than keeping records. =A0So I don't have a bunch of bug repro cases, no= r specific
code that would have been cleane= r had the lower-level functions accepted nil.

The most recent occurrence is relative= ly fresh: =A0I was observing some annoying
= behavior in a Google elisp library -- one that had been doing some path man= ipulation
and choking on nil because, for whatever reason,= `temporary-file-directory' had
been bo= und to nil. =A0So I fixed up the Google function to handle nil the same way=
it handles the empty string. =A0And I glanced ar= ound and noticed that the same
hack had bee= n applied all over the place, sometimes smoothed over with macros
or what have you. =A0It was a lot of smoothing over what appears to be a co= re 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 t= o it.

I'm on = emacs 24 now, and I'll be dutiful about it, but it's going to be an= other year
or two at least before I'm a= ble to respond to the demands for specific examples.
But even then it seems unlikely that I'll re= port the majority of them, because once
peo= ple start=A0asking for hundreds of case-by-case justifications, the battle = is lost.
That's why I tried arguing it from the gener= al case on the first go-round.

But no matter. =A0It was a thought experiment. =A0= I've planted a seed, and maybe
in the coming years people will start evaluating= any occurrences they may
encounter=A0of er= rors on nil-valued string args. =A0In time we may have a corpus of
evidence one way or the other. =A0If not, I'll eventually have a pile o= f examples as
I begin keeping better record= s.

In = the meantime, I very much like Stefan's argument to the effect that pat= ches
speak=A0louder than words. =A0I'll patch my = local copy and start playing with it.

<= /div>
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 assertio= ns, it's unlikely that jumping on that bandwagon will turn the tide.

In the shor= ter term, I hope to be able to get some concrete bug reports around
emacs 24 startup behavior and/or library-loading b= ehavior over the next few
months, now that more of us are using it.
<= div class=3D"gmail_extra">
-steve
=

On Fri, Apr 27, 2= 012 at 2:24 PM, Drew Adams <drew.adams@oracle.com> wrote= :
> I've decided that throwing errors o= n 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 t= he type system,
> we merge two separate meanings of nil. =A0I'm arguing that the
> empty string as it is used today is, for all intents, just
> another nil. =A0So it should not signal an error if they are
> treated the same.

Just because "" and () are similar in some ways does not me= an that they should
be treated as identical in general - any more than [] and () should be. =A0= "For
all intents, just another nil" can apply to a lot of things, including= 0 for
whole numbers. =A0Should we conclude also that throwing errors on nil numbe= rs,
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" (n= ot very clear
to me), and even more specifically to "the smallest set of [core?] fun= ctions
that may originate the infamous `wrong-type-argument (stringp, nil)' er= ror".

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." =A0Surely they do, and in some case= s they raise
an error as a consequence, and in some cases the only possible or the most<= br> appropriate error is the one being decried.

As long as we discuss this at such a general level your argument will not g= o
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 equate= d and raising an error is
wrong. =A0I fear that even this more constrained hand-waving is still unlik= ely to
cut the mustard, but if you nail it down clearly then maybe you can progres= s
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 spe= cific
corner of the type system" that merits such a change, then, by all mea= ns,
identify it rigorously and give supporting arguments.

IOW, be specific about your very specific corner. =A0Specify the problem an= d its
boundaries.

Barring that, I'd add my voice to the advice already given by others: h= andle any
particular functions that you feel ought to treat "" and () the s= ame, 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 distingu= ish
"" from () and to raise an error when () is encountered but "= ;" was expected
(i.e., acceptable). =A0For 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 eq= uate
"" and (). =A0IOW3, 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. =A0In 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. =A0For that, I'= ;m afraid, the
replique given already is the right one: recipe please. =A0It sounds like y= ou or
someone you know has stumbled on a bug that needs fixing. =A0And that, I th= ink, is
the place to start. =A0It is, after all, the real problem behind your real = reason.

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

=A0"If Emacs can't start up, or (worse) it gets into one of
=A0those horrid scenarios where some hook is throwing an error
=A0on almost every command and preventing the user from doing
=A0anything useful, then you're no longer in Emacs. =A0You're in =A0brokenville. =A0All the advantages and pleasure of Emacs as a
=A0dev environment have vanished."

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

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. =A0So your argument about developers vs users, e= ven in
the narrow sense in which it might sometimes be appropriate, does not reall= y
apply here.

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


--20cf30563e47cd6fc804beb5dbe0--