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

[Steve Yegge]

On Thu, Apr 26, 2012 at 6:10 PM, Stefan Monnier <address@hidden> wrote:

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

I can believe that (it's often handy to use "nil-in-nil-out" when
composing functions which may return nil).  

Indeed!

 

But there's also the risk
that you hide real errors, leading to weird behaviors that are more
difficult to track down.

Yes, this is a risk.  However, it's happening right now, as we speak,

all the time.  When stuff works strangely, users find workarounds, and/or

ask developer lists to help them diagnose it.

When stuff doesn't work at all -- which is what happens when Emacs

starts throwing runtime errors -- then it's a lot harder for end-users to

find workarounds.  So it seems to me that we are optimizing for our own

convenience rather than that of end users.

 

E.g. one package uses some other package's var before it's initialized,
so with the current semantics you might get a clean error, whereas with
your proposed semantics you might get some weird behavior where the user
says

 why doesn't bar find my thingy even though C-h v foo-var tells me it's
 set to "/some/path"?

I think we need to be really careful here.  We're talking about these errors

as if they are type assertions in the classic type-theoretic sense, and we

are pointing at the well-documented benefits of early type warnings as a

justification for leaving the errors in place.

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

With that in mind, I'm really wondering what the big fear is here.  As I said,

I'm willing to concede that the generalized nil-always-acts-like-"" solution

may be too risky or too intrusive.  But for the list of specific functions that

I followed up with, I think that for many of them it's quite natural to assume

that they'd take nils.

Here are examples of functions that already take nil as a string argument:

(string< nil "") => nil

(string= nil "") => nil

(concat "a" nil "b")  => "ab" (yes, it's "effectively" taking nil, but it's convenient!)

(string-to-sequence nil 'vector) => []

(string-to-list nil) => nil

I don't see any of these creating world-ending bugs, contrary to predictions.

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.  Yet someone came up with

arbitrary definitions for all all these functions should handle an empty path.

Let's suppose -- bear with me here -- that long ago a mechanism had been

introduced into Emacs to prevent passing the empty string ("") to file-name

manipulation functions, because it's not a valid path on any system.  So

all file-name functions would throw an "invalid path" argument when passed

the empty string.  And let's say I came along and proposed that we ought

to accept the empty string for both user and programmer convenience, as

it is clearly possible to give it reasonable semantics for the entire set of

file-name functions.

In this hypothetical (yet quite similar) scenario, I can guarantee you that

people would be up in arms about how type assertions -- in this case, the

assertion that the path is well-formed by virtue of being nonempty -- can

help find all sorts of errors that might otherwise go undetected.  And there

would be dire predictions about introducing difficult-to-diagnose bugs.

C'mon... we all know this is what would happen.

But the empty strings are just fine.  And the nils will be too.  I promise! =)

-steve