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: Thu, 26 Apr 2012 16:52:31 -0700 Message-ID: References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <87ty06nnxp.fsf@catnip.gol.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf30051378674d4a04be9daed5 X-Trace: dough.gmane.org 1335484369 5621 80.91.229.3 (26 Apr 2012 23:52:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2012 23:52:49 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 01:52:47 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 1SNYUQ-0007va-D1 for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 01:52:46 +0200 Original-Received: from localhost ([::1]:47651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNYUP-0004lT-Pi for ged-emacs-devel@m.gmane.org; Thu, 26 Apr 2012 19:52:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNYUN-0004lC-6C for emacs-devel@gnu.org; Thu, 26 Apr 2012 19:52:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNYUL-0007Bw-BF for emacs-devel@gnu.org; Thu, 26 Apr 2012 19:52:42 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:61255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNYUE-0007Ap-W8; Thu, 26 Apr 2012 19:52:35 -0400 Original-Received: by ghrr18 with SMTP id r18so130344ghr.0 for ; Thu, 26 Apr 2012 16:52:32 -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=mnWEEJpN6ELFMcbdvicU1xg4djCypk1Elj3oJB1MPU8=; b=X4+zT2DA3g4NGClCmW/VhLcVPRhapXBat99q6u0tzX6Ua8JoJbkjCfUib71t8NZCEG 5HJby6wPnUVRHVjGUohOobr3jB8Z4Q3nXjngE0HOWYOGCIJXuoHQIUAeJRmdW/zWp2s6 gFrAJk/Y+YH6eB85PU3/u0pemkn35rhxlSGmCWHNWfq/q7LgTZvZhQL3vVbvDyAOIW0/ vcuF5D8VxkGa4487ve7TaDsrh6Bg02vVXeA1Gz7K7AsGoQj2ITAkXbImYRrJ1+BC0dRP 9cy5/bVvnen4/I52AGrmp1a537L0bRdrt/RkvoD7PbKUT6hPxMajQzeX5pLkEa1dV9ek GvdQ== Original-Received: by 10.236.75.74 with SMTP id y50mr8908862yhd.42.1335484351990; Thu, 26 Apr 2012 16:52:31 -0700 (PDT) Original-Received: by 10.236.156.72 with HTTP; Thu, 26 Apr 2012 16:52:31 -0700 (PDT) In-Reply-To: <87ty06nnxp.fsf@catnip.gol.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.169 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:150070 Archived-At: --20cf30051378674d4a04be9daed5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 26, 2012 at 3:11 PM, Miles Bader wrote: > Steve Yegge writes: > > There's a lot of code out there that's forced to do type assertions on > > string args that could be simplified if these common functions could > > accept nils. > > Maybe. But I think such changes must be justified on a case-by-case > basis, with convincing use-cases ("in this very common situation, a nil > naturally turns up where a string was expected"). > For some of them this might be justified. For others, I see no point in failing to deal with nil values. There is nothing to be gained, and the downside is that some user is sitting there unable to start Emacs because two required packages -- packages that may be used only on demand or not at all -- are arguing over some runtime value. That's a big downside. > Type-checking catches a lot of bugs, even in "loose" languages like lisp > and end-user-targeted languages like elisp -- and I think the trend is > generally towards _stricter_ checking and less fuzziness, even in > scripting languages. It's a big stretch to call the Emacs equivalent of a Java NullPointerException "type checking". A very big stretch. NPEs are notorious for happening too late to be useful. By the time they happen, the root cause is often long gone, produced by something not on the current call stack. Preventing Emacs startup because of a sudden unexpected interaction in package dependencies does not seem like the right way for a text editor to work. -steve > -miles > > -- > Egotist, n. A person of low taste, more interested in himself than in me. > --20cf30051378674d4a04be9daed5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 26, 2012 at 3:11 PM, Miles Bader <miles= @gnu.org> wrote:
Steve Yegge <= steve.yegge@gmail.com> writes:
> There's a lot of code out there that's forced to do type asser= tions on
> string args that could be simplified if these common functions could > accept nils.

Maybe. =A0But I think such changes must be justified on a case-by-cas= e
basis, with convincing use-cases ("in this very common situation, a ni= l
naturally turns up where a string was expected").

For some of them this might be justified. =A0For others, I = see no point in
failing to deal with nil values. =A0There is noth= ing to be gained, and the
downside is that some user is sitting there unable to start Emacs beca= use
two required packages -- packages that may be used only on de= mand or
not at all -- are arguing over some runtime value. =A0Tha= t's a big downside.
=A0
Type-checking catches a lot of bugs, even in "loose" languages li= ke lisp
and end-user-targeted languages like elisp -- and I think the trend is
generally towards _stricter_ checking and less fuzziness, even in
scripting languages.

It's a big stretch= to call the Emacs equivalent of a Java NullPointerException
&quo= t;type checking". =A0A very big stretch. =A0NPEs are notorious for hap= pening
too late to be useful. =A0By the time they happen, the root cause is o= ften long
gone, produced by something not on the current call sta= ck.=A0

Preventing Emacs startup because of a sudde= n unexpected=A0interaction in
package dependencies does not seem like the right way for=A0a text edi= tor to work.

-steve
=A0
-miles

--
Egotist, n. A person of low taste, more interested in himself than in me.

--20cf30051378674d4a04be9daed5--