emacs-devel
[Top][All Lists]
Advanced

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

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


From: Steve Yegge
Subject: Re: proposal to make null string handling more emacs-y
Date: Fri, 27 Apr 2012 12:05:32 -0700

On Thu, Apr 26, 2012 at 11:36 PM, Eli Zaretskii <address@hidden> wrote:
> Date: Thu, 26 Apr 2012 21:17:36 -0700
> From: Steve Yegge <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden
>
> 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

reply via email to

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