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

[Steve Yegge <steve.yegge@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

On Thu, Apr 26, 2012 at 11:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 26 Apr 2012 21:17:36 -0700
> > From: Steve Yegge <steve.yegge@gmail.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >
> > But type errors are for *developers*.  They are supposed to happen at
> > compile time.  When you're running the byte compiler or the unit tests,
> you
> > want it to fail loudly and early.
>
> This is Lisp, not C++ or even Java.  Some Lisp code is never compiled
> at all.  A notable example is the code you put in .emacs.


Perhaps we need a strict mode, then.


> > But when you ship the software, and it's in the hands of end-users
> > who may not be able to debug it, then unless it's running a nuclear
> > reactor or an airplane, you want the software to be robust.  Your
> > browser shouldn't crash because of a misbehaved site; your web page
> > shouldn't fail to load because of a misbehaved widget; your CAD
> > program shouldn't stop functioning because of a misbehaved polygon.
> > Yes, the resulting bug will be annoying, but it's far less annoying
> > than having your work interrupted altogether.
>
> I don't think you can have an interpreted language without runtime
> exceptions.  In Lisp, if you want robust programs, you need to catch
> exceptions and do something reasonable.  Asking to avoid exceptions
> altogether is IMO impractical.
>

I agree with you.  Fortunately that's not what I'm arguing.  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.


> > Similarly, I see a whole bunch of file-name manipulation functions that
> > accept the empty string as an argument.  But the empty string has no
> > semantic meaning whatsoever as a valid filename.  Without any semantic
> > meaning, it's arguably a bug to pass one in.
>
> The usual Emacs semantics for an empty file name is that it stands for
> the current directory.
>

 That sounds like a wonderful semantics for a nil filename.

-steve

[-- Attachment #2: Type: text/html, Size: 3192 bytes --]