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

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

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

On Thu, Apr 26, 2012 at 6:10 PM, Stefan Monnier <monnier@iro.umontreal.ca>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

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