proposal to make null string handling more emacs-y

proposal to make null string handling more emacs-y

[Steve Yegge]

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

I haven't started a big flamewar and made fresh new enemies in what has
to be at least three weeks.  So.  Here goes.

I think we should change all the core string-manipulation functions to deal
gracefully with nil arguments.  Specifically, I want to change the smallest
set of functions that may originate the infamous "wrong-type-argument
(stringp, nil)" error, making them instead treat nil as if it were the
empty string.

By way of justification:

  * it's Lispy.  Yes, most Lisp dialects got strings wrong, but that
shouldn't
    stop us.  Strings are just character sequences, and whether you like it
or
    not, the nil/empty-list equivalence is part of Emacs's soul.  Throwing
an
    error on a nil string is a radical departure from the core philosophy.

  * wrong-type-argument (stringp, nil) is, anecdotally speaking, both the
most
    common error encountered by casual users and the most feared, because
    it's incredibly difficult to debug.  What's so hard about debugging it?
    It prevents Emacs from starting up!  So your debugger, evaluator, etc.
are
    all useless, and you're back to binary-partitioning of your .emacs file
until you
    find the offending code.  Setting debug-on-error works for more
experienced
    users, *when* it works (which, combined with --debug-init is not very
often).
    But even then, emacs stack traces are a poor-man's debugging tool at
best.

  * changing the behavior is unlikely to break much code.  Emacs libraries
should
    already do nil-checking on string arguments.  And nobody should be
relying
    on error conditions for normal control flow, so no code should be
depending
    on the string functions signaling this error.

The second argument is the real reason I've come to believe we're doing it
wrong.
Emacs has amazingly powerful runtime debugging facilities.  When Emacs is
running, it's *_*alive_, and you can help newbies debug problems by sending
them
snippets of code to evaluate on the fly.

If Emacs can't start up, or (worse) it gets into one of those horrid
scenarios where
some hook is throwing an error on almost every command and preventing the
user
from doing anything useful, then you're no longer in Emacs.  You're in
brokenville.
All the advantages and pleasure of Emacs as a dev environment have vanished.

In a way, I am arguing that Emacs is different from most other software, in
that
it is better for Emacs to fail silently and keep running than it is to fail
noisily and
prevent the user from doing any work.  This is not by any means an argument
you'd make about most software.  But over twenty-five years of daily Emacs
use,
I've decided that throwing errors on nil strings -- however good the
intentions may
have been -- is doing more harm than good.

Before you reject the idea out of hand, I'd like to ask that you consider
carefully
what behavior would be most consistent with the rest of Emacs, and would
make
best use of existing debugging and diagnostic facilities.

Compared to lexical scoping, this change is pretty minor. ;-)

-steve

p.s. (string= nil "") would still yield nil, of course.  I'm proposing
that we treat nil
as the empty string, not the other way around.

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

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

[Karl Fogel]

Steve Yegge <steve.yegge@gmail.com> writes:
>Before you reject the idea out of hand, I'd like to ask that you
>consider carefully
>what behavior would be most consistent with the rest of Emacs, and
>would make
>best use of existing debugging and diagnostic facilities.
>
>Compared to lexical scoping, this change is pretty minor. ;-)
>
>-steve
>
>p.s. (string= nil "") would still yield nil, of course.  I'm proposing
>that we treat nil
>as the empty string, not the other way around.

Have you tried making the change in a dev tree and seeing what the first
things to break are?

I'm not sold on the idea anyway, I have to admit -- that "wrong-type"
error has been a valuable source of early bug detection for me many
times -- but the above seems like a worthwhile experiment for those who
like the proposal and want to investigate it.

-K

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

[Miles Bader]

Steve Yegge <steve.yegge@gmail.com> writes:
>   * it's Lispy.  Yes, most Lisp dialects got strings wrong, but that
> shouldn't stop us.  Strings are just character sequences, and whether
> you like it or not, the nil/empty-list equivalence is part of Emacs's
> soul.  Throwing an error on a nil string is a radical departure from
> the core philosophy.

That's a pretty dubious claim...

-miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

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

[Miles Bader]

>   * wrong-type-argument (stringp, nil) is, anecdotally speaking, both
> the most common error encountered by casual users and the most feared,
> because it's incredibly difficult to debug.  What's so hard about
> debugging it?  It prevents Emacs from starting up!

Come to think of it, _this_ is a pretty dubious claim too (or rather,
it's a collection of dubious claims)...

-miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

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

[Ted Zlatanov]

On Wed, 25 Apr 2012 15:28:59 +0900 Miles Bader <miles@gnu.org> wrote: 

MB> Steve Yegge <steve.yegge@gmail.com> writes:
>> * it's Lispy.  Yes, most Lisp dialects got strings wrong, but that
>> shouldn't stop us.  Strings are just character sequences, and whether
>> you like it or not, the nil/empty-list equivalence is part of Emacs's
>> soul.  Throwing an error on a nil string is a radical departure from
>> the core philosophy.

MB> That's a pretty dubious claim...

I see strings as a vector sequence, not a list sequence.  Thus:

(null (make-vector 0 "hello"))
=> nil

(null (make-list 0 "hello"))
=> t

So it makes sense to me that an empty string would be more like a
0-length vector.  This is a painful area in Perl[1], which treats undef
*and* several strings as equivalent in a boolean context.  I think it
would be painful in Emacs Lisp too.

Ted

[1] http://www.perlmonks.org/?node_id=862 and many others

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

[Randal L. Schwartz]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> So it makes sense to me that an empty string would be more like a
Ted> 0-length vector.  This is a painful area in Perl[1], which treats undef
Ted> *and* several strings as equivalent in a boolean context.  I think it
Ted> would be painful in Emacs Lisp too.

Seconded.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

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

[Helmut Eller]

* Steve Yegge [2012-04-25 00:24] writes:

> I haven't started a big flamewar and made fresh new enemies in what has
> to be at least three weeks.  So.  Here goes.
>
> I think we should change all the core string-manipulation functions to deal
> gracefully with nil arguments.  Specifically, I want to change the smallest
> set of functions that may originate the infamous "wrong-type-argument
> (stringp, nil)" error, making them instead treat nil as if it were the empty
> string.

The smallest set of those functions seems to be the empty set (aka. nil
or was it ""?).

Helmut

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

[Eli Zaretskii]

> Date: Tue, 24 Apr 2012 17:24:57 -0700
> From: Steve Yegge <steve.yegge@gmail.com>
> 
> I think we should change all the core string-manipulation functions to deal
> gracefully with nil arguments.  Specifically, I want to change the smallest
> set of functions that may originate the infamous "wrong-type-argument
> (stringp, nil)" error, making them instead treat nil as if it were the
> empty string.

I'm quite sure this will break gobs of existing code in Emacs.  The
entire display engine, for starters.

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

[Stefan Monnier]

>> I think we should change all the core string-manipulation functions to deal
>> gracefully with nil arguments.  Specifically, I want to change the smallest
>> set of functions that may originate the infamous "wrong-type-argument
>> (stringp, nil)" error, making them instead treat nil as if it were the
>> empty string.

Being a type zealot, I'm not sure I like this idea.

This said, I'm not necessarily opposed to it.  The argument that it's
a super-common error and that it's always hard to debug doesn't convince
me (I haven't noticed it to be significantly more frequent than other
errors, nor that it's hard to debug).  BTW, we shouldn't accept "hard to
debug" as a fatality: we should try to make it easier.

So I'd like to see an actual proposed patch for one, and some further
arguments about why it would be a goo idea.

> I'm quite sure this will break gobs of existing code in Emacs.  The
> entire display engine, for starters.

I wonder what makes you think that would introduce lots of bugs,
and why in the display engine.

AFAICT this error is very rarely thrown, so turning it into some other
behavior should have very little effect, if any.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Steve Yegge <steve.yegge@gmail.com>,  emacs-devel@gnu.org
> Date: Wed, 25 Apr 2012 10:28:05 -0400
> 
> > I'm quite sure this will break gobs of existing code in Emacs.  The
> > entire display engine, for starters.
> 
> I wonder what makes you think that would introduce lots of bugs,
> and why in the display engine.

Code out there depends on nil being different from an empty string.
In the display engine, if a string is nil, that's used as a flag.

> AFAICT this error is very rarely thrown, so turning it into some other
> behavior should have very little effect, if any.

The suggestion, AFAIU, wasn't limited to error being thrown.

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

[Stefan Monnier]

>> > I'm quite sure this will break gobs of existing code in Emacs.  The
>> > entire display engine, for starters.
>> I wonder what makes you think that would introduce lots of bugs,
>> and why in the display engine.
> Code out there depends on nil being different from an empty string.
> In the display engine, if a string is nil, that's used as a flag.

AFAIK he's not suggesting to change that.  He's only suggesting that
instead of throwing an error some functions should behave as if they had
received an empty string.  E.g. like (concat "23" nil "45") does.


        Stefan

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

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> AFAIK he's not suggesting to change that.  He's only suggesting that
> instead of throwing an error some functions should behave as if they had
> received an empty string.  E.g. like (concat "23" nil "45") does.

Also kinda like the old "strlen (NULL) => 0" behavior (and generally,
derefencing a pointer => 0)...

Which was (1) sort of handy in some cases, and (2) really good at
hiding bugs...

-miles

-- 
XML is like violence.  If it doesn't solve your problem, you're not
using enough of it.

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

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> E.g. like (concat "23" nil "45") does.

That's not a good example since concat explicitly accepts lists as
arguments.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Juanma Barranquero]

On Wed, Apr 25, 2012 at 17:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> He's only suggesting that
> instead of throwing an error some functions should behave as if they had
> received an empty string.  E.g. like (concat "23" nil "45") does.

Though, to be fair, `concat' is not special-casing anything. It's not
behaving as if it had received an empty string, but an empty list:

ELISP> (concat "ab" '(?x) "cd")
"abxcd"
ELISP> (concat "ab" '() "cd")
"abcd"

(Yes, I know you know it.)

    Juanma

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

[Steve Yegge]

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

If the general change is too risky, I think there are still a few functions
that
would benefit from being able to accept nils on a case-by-case basis.
Examples:

looking-at, string-match, search-forward-*
string-to-list, string-to-vector, (maybe) string-to-number
auto-save-file-name-p, backup-file-name-p
directory-file-name, expand-file-name, file-name-as-directory and their ilk
(all of which handle "" gracefully)
rename-file, copy-file, delete-file ("no such file/dir" being more
informative than "wrong type argument" here)
write-file (prompts on empty string; might as well prompt on nil)

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.

-steve

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

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

[Miles Bader]

Steve Yegge <steve.yegge@gmail.com> 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").

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.

-miles

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

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

[Steve Yegge]

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

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

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

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

[Miles Bader]

Steve Yegge <steve.yegge@gmail.com> writes:
>> 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.

Signalling an error _is_ "dealing with nil values" (and very often the
correct way).

Anyway, I think the onus is on you to show that relaxing
error-checking is justified.

> There is nothing to be gained

Clearly there is:  less buggy code.

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

WTF do you keep going on about Emacs startup?

If Emacs is dealing poorly with errors during startup -- of which
nil-when-a-string-was-expected is just one not particularly noteworthy
example -- then Emacs' handling of errors during startup needs to be
made robust.

Just papering over the problem by ignoring bugs simply means Emacs
will be more buggy.  That hurts users.

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

Use whatever terminology you like.  It doesn't change the issues.

-miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

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

[Jeremiah Dodds]

Miles Bader <miles@gnu.org> writes:

> Steve Yegge <steve.yegge@gmail.com> writes:
>> 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.
>
> WTF do you keep going on about Emacs startup?

I believe this is because it seems that the "uh-oh i got a nil when I
expected a string" error commonly happens on emacs startup, confusing
new users, presumably after loading some big bunch of elisp.

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

[Miles Bader]

Jeremiah Dodds <jeremiah.dodds@gmail.com> writes:
>>> 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.
>>
>> WTF do you keep going on about Emacs startup?
>
> I believe this is because it seems that the "uh-oh i got a nil when I
> expected a string" error commonly happens on emacs startup, confusing
> new users, presumably after loading some big bunch of elisp.

Does it?  I don't think I've _ever_ seen that error at startup (though
I've certainly had errors during startup)...

-miles

-- 
Cynic, n. A blackguard whose faulty vision sees things as they are, not as
they ought to be. Hence the custom among the Scythians of plucking out a
cynic's eyes to improve his vision.

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

[Jeremiah Dodds]

Miles Bader <miles@gnu.org> writes:

> Jeremiah Dodds <jeremiah.dodds@gmail.com> writes:
>>>> 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.
>>>
>>> WTF do you keep going on about Emacs startup?
>>
>> I believe this is because it seems that the "uh-oh i got a nil when I
>> expected a string" error commonly happens on emacs startup, confusing
>> new users, presumably after loading some big bunch of elisp.
>
> Does it?  I don't think I've _ever_ seen that error at startup (though
> I've certainly had errors during startup)...
>
> -miles

It's happened to me enough times over the course of the decade or so
that I've been using emacs to remember it. I know that the first few
times it happened, I was pretty green and got really confused for a
while. Nowadays, I know how to figure out wtf is going on.

Unfortunately I don't remember the specifics of what triggered the error
for any of the times I ran into the issue.

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

[Miles Bader]

Jeremiah Dodds <jeremiah.dodds@gmail.com> writes:
>>> I believe this is because it seems that the "uh-oh i got a nil when I
>>> expected a string" error commonly happens on emacs startup, confusing
>>> new users, presumably after loading some big bunch of elisp.
>>
>> Does it?  I don't think I've _ever_ seen that error at startup (though
>> I've certainly had errors during startup)...
>
> It's happened to me enough times over the course of the decade or so
> that I've been using emacs to remember it. I know that the first few
> times it happened, I was pretty green and got really confused for a
> while. Nowadays, I know how to figure out wtf is going on.

Startup is typically a particularly intense period of elisp execution
in a short period of time, so it's not surprising if errors are more
noticeable there, and particularly annoying, because they often leave
Emacs in an uncertain state.

But:

(1) This particular type of error (nil when string expected) is just
    as, or even more, likely to occur over the rest of Emacs'
    execution.

(2) Many other types of errors (whether bugs or transient errors
    because of e.g. environmental issues or something [can't open some
    file, network down, ...]) can occur during startup

So there doesn't really seem to be all that much correlation between
what Steve was complaining about and startup.  To the extent his
complaint is valid, it's a general issue, not a "startup issue."

Moreover, if Emacs is clumsy at handling errors during startup (and I
agree that it is), that's a problem that should be addressed generally
in the startup mechanism, not by bandaids on only vaguely related
areas.

In other words, these these things look largely orthogonal.

[If this particular bandaid were harmless maybe it should be added
anyway, as a stop-gap to a more proper solution -- but it isn't
harmless, at least when applied generally; in certain cases, it may
be, of course.]

-Miles

-- 
`Life is a boundless sea of bitterness'

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

[Thien-Thi Nguyen]

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

() Miles Bader <miles@gnu.org>
() Fri, 27 Apr 2012 13:24:05 +0900

   To the extent his complaint is valid,
   it's a general issue, not a "startup issue."

   Moreover, if Emacs is clumsy at handling errors during startup
   (and I agree that it is), that's a problem that should be
   addressed generally in the startup mechanism, not by bandaids
   on only vaguely related areas.

   In other words, these these things look largely orthogonal.

   [If this particular bandaid were harmless maybe it should be
   added anyway, as a stop-gap to a more proper solution -- but it
   isn't harmless, at least when applied generally; in certain
   cases, it may be, of course.]

I have always longed for ‘load-in-progress’ to be, instead of a
simple boolean, a counter of top-level forms (from a particular
file/buffer).  This light-weight mechanism could speed debugging
by providing more specific information:

ok:
An error occurred while loading `/home/ttn/.emacs':

better:
An error occurred while loading `/home/ttn/.emacs' (Nth form):

This could be used by the ‘--debug-init’ machinery, as well.  On
second thought (after glancing at lread.c ‘readevalloop’), even
more direct would be simply to record the "position of the current
top-level form".  From *Backtrace* (invoking with ‘--debug-init’),
evaluating expression:

(with-current-buffer " *load*" (point))

yields related information, the "position just past the current
top-level form", so i suppose everything can be done in Lisp, by
providing:

(with-current-buffer " *load*"
  (save-excursion (forward-sexp -1) (point)))

in some non-expert-friendly way, after which, we can banish the
laconic "bisect ~/.emacs" to the /second/ advised step (when the
user realizes that it is not the current top-level form or its
progeny that is the Real Problem, but some bad interaction between
those and the other loosely-included cargo-cult copy-pasta).  :-/

But hey, one step at a time...

[To reproduce the above observations, create file /tmp/bad with
contents "zorg", and add ‘(load-file "/tmp/bad")’ somewhere in
~/.emacs (or other init file).]

Hmm, i just noticed that *Backtrace* now (as of 2005-07-10)
displays the "just past" position for all frames, so i suppose to
boil down this long post into something constructive, how about:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: debug.el.diff --]
[-- Type: text/x-diff, Size: 2493 bytes --]

 lisp/emacs-lisp/debug.el |   24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index b0813ae..bda05ac 100644
*** a/lisp/emacs-lisp/debug.el
--- b/lisp/emacs-lisp/debug.el
***************
*** 333,351 ****
                  (cdr debugger-args) debugger-args)
              (current-buffer))
       (insert ?\n)))
!   ;; After any frame that uses eval-buffer,
    ;; insert a line that states the buffer position it's reading at.
    (save-excursion
!     (let ((tem eval-buffer-list))
        (while (and tem
  		  (re-search-forward "^  eval-\\(buffer\\|region\\)(" nil t))
  	(end-of-line)
! 	(insert (format "  ; Reading at buffer position %d"
  			;; This will get the wrong result
  			;; if there are two nested eval-region calls
  			;; for the same buffer.  That's not a very useful case.
  			(with-current-buffer (car tem)
! 			  (point))))
  	(pop tem))))
    (debugger-make-xrefs))

--- 333,367 ----
                  (cdr debugger-args) debugger-args)
              (current-buffer))
       (insert ?\n)))
!   ;; After any frame that uses eval-buffer, for `read'-related error,
    ;; insert a line that states the buffer position it's reading at.
+   ;; For other errors, state the buffer position of the offending form.
    (save-excursion
!     (let ((tem eval-buffer-list)
!           (read-related-error-p
!            (and
!             ;; A `read'-related error, if any, is always singular and innermost.
!             (eq 'error (car debugger-args))
!             (memq (car (cadr debugger-args))
!                   ;; This is from grep xsignal1 lread.c -- is that OK?
!                   '(end-of-file
!                     invalid-read-syntax
!                     overflow-error)))))
        (while (and tem
  		  (re-search-forward "^  eval-\\(buffer\\|region\\)(" nil t))
  	(end-of-line)
! 	(insert (format "  ; Reading%s at buffer position %d"
! 			(if read-related-error-p "" " form")
  			;; This will get the wrong result
  			;; if there are two nested eval-region calls
  			;; for the same buffer.  That's not a very useful case.
  			(with-current-buffer (car tem)
! 			  (if read-related-error-p
!                               (point)
!                             (save-excursion
!                               (forward-sexp -1)
!                               (point))))))
!         (setq read-related-error-p nil)
  	(pop tem))))
    (debugger-make-xrefs))

[-- Attachment #3: Type: text/plain, Size: 173 bytes --]


This distinguishes between ‘read’-related and other errors, but
i'm unsure if the way of discernment is correct.  (Too, it could
be reworked to use ‘pcase’...)

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

[Nix]

On 27 Apr 2012, Miles Bader uttered the following:
> (1) This particular type of error (nil when string expected) is just
>     as, or even more, likely to occur over the rest of Emacs'
>     execution.

FWIW I saw this error very recently. It turned out to be a magit bug
that could I believe have potentially caused data loss, so I'm very glad
it was diagnosed so I could fix it -- even if it *was* annoying at first
to have to debug this with a crippled (i.e. -Q) emacs.

-- 
NULL && (void)

Better startup error handling (was: proposal to make null string handling more emacs-y)

[Stefan Monnier]

> Moreover, if Emacs is clumsy at handling errors during startup (and I
> agree that it is), that's a problem that should be addressed generally

If someone wants to attack this, I'm all ears.

The way I see it, we should ideally be able to load the .emacs in such
a way that an error doesn't prevent the rest of the file from being
loaded, and the error should be clearly signaled to the user with some
kind of line-number information.

In my wildest dreams I also imagine that we'd check for obsolete vars,
hooks, and functions.  Maybe even give the same kind of feedback that
the byte-compiler gives about the code.


        Stefan

Re: Better startup error handling

[Nix]

On 28 Apr 2012, Stefan Monnier spake thusly:

> The way I see it, we should ideally be able to load the .emacs in such
> a way that an error doesn't prevent the rest of the file from being
> loaded, and the error should be clearly signaled to the user with some
> kind of line-number information.

Yes. This presumably means some sort of evaluator hook to execute some
code between each toplevel form, or wrap each top-level form in a
condition-case -- reader macros would I think handle it, but elisp
doesn't have those.

> In my wildest dreams I also imagine that we'd check for obsolete vars,
> hooks, and functions.  Maybe even give the same kind of feedback that
> the byte-compiler gives about the code.

Can't you do that trivially by loading .emacs into a temporary buffer in
default.el, then byte-compiling it and throwing the results away?
(In default.el because that way it picks up changes to the byte-compiler
configuration that you may have made in .emacs.)

Downsides: loads the byte-compiler even in sessions that don't need it,
and notably inefficient.

-- 
NULL && (void)

Re: Better startup error handling

[Stefan Monnier]

>> The way I see it, we should ideally be able to load the .emacs in such
>> a way that an error doesn't prevent the rest of the file from being
>> loaded, and the error should be clearly signaled to the user with some
>> kind of line-number information.
> Yes.  This presumably means some sort of evaluator hook to execute some
> code between each toplevel form, or wrap each top-level form in a
> condition-case -- reader macros would I think handle it, but elisp
> doesn't have those.

Another way to do it is to not use `load' but to find-file .emacs and
then eval-region chunk by chunk.

>> In my wildest dreams I also imagine that we'd check for obsolete vars,
>> hooks, and functions.  Maybe even give the same kind of feedback that
>> the byte-compiler gives about the code.
> Can't you do that trivially by loading .emacs into a temporary buffer in
> default.el, then byte-compiling it and throwing the results away?
> (In default.el because that way it picks up changes to the byte-compiler
> configuration that you may have made in .emacs.)

Kind of.

> Downsides: loads the byte-compiler even in sessions that don't need it,
> and notably inefficient.

Exactly: in theory it's straightforward, but doing it well will require
more work.  IIRC there are some other issues such as the fact that
.emacs code tends to be very different from typical code in Elisp
packages, and the kinds of things we want to flag aren't all the same
(some things are acceptable/normal/unavoidable in one but not in the
other).


        Stefan

Re: Better startup error handling

[David Engster]

Stefan Monnier writes:
>>> The way I see it, we should ideally be able to load the .emacs in such
>>> a way that an error doesn't prevent the rest of the file from being
>>> loaded, and the error should be clearly signaled to the user with some
>>> kind of line-number information.
>> Yes.  This presumably means some sort of evaluator hook to execute some
>> code between each toplevel form, or wrap each top-level form in a
>> condition-case -- reader macros would I think handle it, but elisp
>> doesn't have those.
>
> Another way to do it is to not use `load' but to find-file .emacs and
> then eval-region chunk by chunk.

FWIW, I've written this for creating profiles of the init file:

http://www.emacswiki.org/emacs/ProfileDotEmacs

-David

RE: Better startup error handling

[Drew Adams]

> > Downsides: loads the byte-compiler even in sessions that 
> > don't need it, and notably inefficient.
> 
> Exactly: in theory it's straightforward, but doing it well 
> will require more work.  IIRC there are some other issues such as
> the fact that .emacs code tends to be very different from typical
> code in Elisp packages, and the kinds of things we want to flag
> aren't all the same (some things are acceptable/normal/unavoidable
> in one but not in the other).

No flames please, but I have a different objection to this idea.  Perhaps you
hinted at in in your last sentence - not sure.  Anyhooo...

.emacs is something that many non-Lisper users use.  Sometimes they load
3rd-party libraries from it.  Sometimes they include 3rd-party snippets directly
in it.  Whether that makes sense in general or for any given library or snippet
is beside the point here.  It is done, and rather often, I believe.

Some such libraries or snippets are designed to work with more than one Emacs
version.  As such, it can be the case that some of the byte-compiler warnings,
e.g. function calls with the wrong number of args or functions not known to be
defined, are not relevant in the end.  The byte compiler is just not smart
enough to get everything right, and understandably so.

That is, some such warnings might be relevant and helpful to some users and are
probably so to developers of the libraries or snippets included, but they are
not necessarily relevant to some other users.  And those are the users whom we
are most worried about wrt the thread Subject line.  They are the users who are
least likely to know what to do when they run into a startup problem etc.

And - and this is important in my experience - some users do not understand, or
misunderstand, when then see such warnings.  Warnings can even frighten people
when they are not understood.  I've gotten more than one question or bug report
which I replied to by reassuring the user that some such warning is not really
relevant in the current situation etc.  I'm probably not alone in that.

In sum, my objection is that we will be throwing warnings at users who will not
necessarily understand them and will not necessarily need to see them anyway.
And yes, I do think this is potentially a big problem, for both users and the
developers of code they use.  Throwing byte-compiler warnings at users to handle
or prevent startup problems is the wrong cure, IMHO - really wrong.

The byte compiler for any given Emacs version is what it is.  It can be helpful
but it is certainly not perfect.  And in particular it is not always on target
when it comes to code that has to work with different Emacs versions.

This problem tends to get worse as the byte compiler gets more helpful (almost
put that word in quotes ;-)), more verbose, more finnicky.  Systematically
applying the byte compiler to user .emacs files sounds like a colossally
misguided idea, to me.

Re: Better startup error handling

[Stefan Monnier]

>> > Downsides: loads the byte-compiler even in sessions that 
>> > don't need it, and notably inefficient.
>> Exactly: in theory it's straightforward, but doing it well 
>> will require more work.  IIRC there are some other issues such as
>> the fact that .emacs code tends to be very different from typical
>> code in Elisp packages, and the kinds of things we want to flag
>> aren't all the same (some things are acceptable/normal/unavoidable
>> in one but not in the other).
> No flames please, but I have a different objection to this idea.
> Perhaps you hinted at in in your last sentence - not sure.  Anyhooo...

I largely agree, and that's indeed some of the issues I was hinting at.
Rather than try to detect errors (such as wrong-number of args) which
will/would be detected at run-time anyway, the purpose would be to
detect use of obsolete/deprecated vars/functions/functionality.

But as you mention, such warnings should be kept sufficiently discreet
since a user may elect to keep "old" code if she uses the same .emacs
with various versions/flavors of emacs.


        Stefan

Re: Better startup error handling

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The way I see it, we should ideally be able to load the .emacs in such
> a way that an error doesn't prevent the rest of the file from being
> loaded, and the error should be clearly signaled to the user with some
> kind of line-number information.

Yeah, that's a very good idea.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Better startup error handling

[Christian Lynbech]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Moreover, if Emacs is clumsy at handling errors during startup (and I
>> agree that it is), that's a problem that should be addressed generally

Stefan> If someone wants to attack this, I'm all ears.

One suggestion that at least would help me a lot debugging problems
during startup would be if emacs maintained some sort of stack of files
being loaded. In other words, whenever an exception happens, there would
be a way to see that not only did evaluation halt during such-and-such
form but it happened during the load of file B that was loaded from file
A that was in turn loaded from .emacs.

In most cases, the actual error that halts the startup provides very
little info by itself and it is almost always something that happens in
one of the many libraries that I load during startup. Moreover,
frequently the library is not really at fault but I am doing something
(or fail to do something) that is (no longer) valid for my usage of the
library. 

My .emacs is big enough that I have split it into a number of files so
when I have problems, I must normally first evaluate .emacs form by form
to find the next level culprit, then repeat the form-by-form evaluation
of that to find which library to investigate. If I had some form of
loading stack, I would know immediately.

Obviously, there is tradeoff between newbie usability and guru info
provided. It would be fine by me that such debugging info was not showed
into the face of an innocent user but still was available to the
knowledgeable. If we even could save some information about both error
and the evaluation stack leading up to it, such that one was not forced
to start over with some fancy option to get usable feedback, it would be
double good. I these modern times, a lot of people do not start emacs
from the commandline and thus may even have issues knowing how to do
that.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Better startup error handling

[chad]

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


On Apr 30, 2012, at 1:43 AM, Christian Lynbech wrote:
> 
> Obviously, there is tradeoff between newbie usability and guru info
> provided.

As a practical matter, don't most gurus set debug-on-error 't early in .emacs anyway?  If not, I'd be curious as to why - that's been the first line of my .emacs more or less forever, and I thought it was common practice.

*Chad





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

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

[Richard Stallman]

    I believe this is because it seems that the "uh-oh i got a nil when I
    expected a string" error commonly happens on emacs startup, confusing
    new users, presumably after loading some big bunch of elisp.

This sort of error -- at startup or not -- is a sign of a real bug, a
variable not properly set up.  Making string functions not signal
errors would paper it over, which does not mean things would work
correctly.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Stefan Monnier]

> 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).  But there's also the risk
that you hide real errors, leading to weird behaviors that are more
difficult to track down.
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"?


-- Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I can believe that (it's often handy to use "nil-in-nil-out" when
> composing functions which may return nil).  But there's also the risk
> that you hide real errors, leading to weird behaviors that are more
> difficult to track down.

I see allowing more nil values in string-ey functions as a very Lisp-ey
thing to do.

I'm really really happy that Emacs Lisp isn't Scheme-like.  Stuff like

(assq 'foo bar) ⇒  #f

would just drive me totally batty.

Battier.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Richard Stallman]

 
    I'm really really happy that Emacs Lisp isn't Scheme-like.  Stuff like

    (assq 'foo bar) ⇒  #f

    would just drive me totally batty.

I think splitting apart the different meanings of nil in Lisp
was an unfortunate mistake in Scheme.  This sort of cleanliness
is only desirable theoretically, not in practice.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Eli Barzilay]

Richard Stallman <rms@gnu.org> writes:

>  
>     I'm really really happy that Emacs Lisp isn't Scheme-like.  Stuff like
>
>     (assq 'foo bar) ⇒  #f
>
>     would just drive me totally batty.
>
> I think splitting apart the different meanings of nil in Lisp was an
> unfortunate mistake in Scheme.  This sort of cleanliness is only
> desirable theoretically, not in practice.

As a (semi-fake) "Schemer", I can say that it's perfectly fine in
practice too.  It catches real errors.  In analogy to what you wrote a
few seconds later -- it catches errors that would otherwise get
papered over.

There's obviously a subjective line here, where Elisp and Scheme are
going in different directions, and IIUC, Steve's point is that "" =~
nil is continuing in the same direction that elisp already went to.
(But of course the question is how far you're willing to go, otherwise
you end up with "wat".)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

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

[Richard Stallman]

    As a (semi-fake) "Schemer", I can say that it's perfectly fine in
    practice too.  It catches real errors.  In analogy to what you wrote a
    few seconds later -- it catches errors that would otherwise get
    papered over.

The benefit of making () and false the same in Lisp is NOT a matter of
suppressing errors.  The benefit is that we can simplify programs by
knowing that () and false are the same.

If these cases happen in Scheme, they are errors.  However, in Lisp it
is very convenient that the empty list also represents false.

Equating () and "" might perhaps give some benefit of simplifying
programs.  You could try looking for places where you could take
advantage of that, to see how much convenience it gives.  But this is
a different matter from avoiding errors.

I tend to think the benefit won't be big, but you can try to show
I'm wrong.

I am not sure there is any benefit to the fact that () is the same as
(intern "nil").

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Stefan Monnier]

> I am not sure there is any benefit to the fact that () is the same as
> (intern "nil").

Indeed, it's actually something I dislike about Elisp (whereas I found
the ()=false to be really handy, just like the 0=NULL= false in C).

I've never found it to be useful, and it can be really inconvenient when
you need to distinguish "a symbol" from "just the nil value".


        Stefan

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

[Eli Barzilay]

Four hours ago, Richard Stallman wrote:
>     As a (semi-fake) "Schemer", I can say that it's perfectly fine in
>     practice too.  It catches real errors.  In analogy to what you wrote a
>     few seconds later -- it catches errors that would otherwise get
>     papered over.
> 
> The benefit of making () and false the same in Lisp is NOT a matter
> of suppressing errors.

Sure it is.  (null? (< 1 2)) makes no semantic sense, and you get an
error.  In other lisps, (null (< 1 2)) makes no sense but instead of
an error you get a convention of preferring `not'.  The error that
Scheme throws is suppressed, but using `null' like that is likely to
be an error.  (BTW, Scheme itself is doing the same when it treats any
non-#f value as true.  CLers would also argue that Scheme is also
doing it when it treats identifiers in function positions the same as
elsewhere.)


> The benefit is that we can simplify programs by knowing that () and
> false are the same.

Right, and you get more of these benefits if it's also the same as ""
and as 0, and there are additional benefits in the same direction:
allow using `nil' as a function (that returns `nil' when called),
allow adding numbers, strings, lists, etc with implicit coercions,
maybe allow using numbers and lists as functions (as in arc), and
allow referring to undefined variables and calling undefined
functions.

Each of these simplifies (and shortens) existing code, since they each
encapsulate common code pattern.  But each of these suppresses more
bugs since more defective code runs to completion, returning bogus
results instead of throwing an error.  (I'm talking about defective in
the sense of diverging from what the code should do, not in a
technical execution sense where they're no longer bugs.)

Note in particular that all of these are directly contributing to
Steve's proposal: they lead to less frustraing errors, since more code
will run without exceptions, implicitly doing something that likely
should be done in today's elisp.  Note also his reference to running
code in a browser, where JS is a language that is very intentionally
doing its best to continue running, with modern browsers going farther
by not even showing most people errors.

Arguing that some of these things are better or worse is wrong.  It
doesn't make sense to reject unifying "" and `nil' on one hand and
reject separating false and '() on the other -- *unless* it's clear
that it's a subjective decision.  They are very clearly tradeoffs of
convenience vs robustness.

So the argument is not "scheme is wrong to distinguish false from nil,
elisp is right to distinguish the empty string from nil".  Instead, it
should be an argument about the decision that most elispers do, and
finding the right place on the line.


> Equating () and "" might perhaps give some benefit of simplifying
> programs.  You could try looking for places where you could take
> advantage of that, to see how much convenience it gives.  But this
> is a different matter from avoiding errors.

(Avoiding errors is what started this thread...)


> I tend to think the benefit won't be big, but you can try to show
> I'm wrong.

(I'm making a meta point about the argument, I don't have any
preference for either side.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

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

[Richard Stallman]

    > The benefit of making () and false the same in Lisp is NOT a matter
    > of suppressing errors.

    Sure it is.  (null? (< 1 2)) makes no semantic sense, and you get an
    error.  In other lisps, (null (< 1 2)) makes no sense 

It does make sense.  The distinction made in Scheme between nil and false
does not exist.  `null' and `not' are equivalent; it is not a matter
of using one meaning a fallback for another.

That () and false are the same object is a feature.

    > The benefit is that we can simplify programs by knowing that () and
    > false are the same.

    Right, and you get more of these benefits if it's also the same as ""
    and as 0, and there are additional benefits in the same direction:
    allow using `nil' as a function (that returns `nil' when called),
    allow adding numbers, strings, lists, etc with implicit coercions,
    maybe allow using numbers and lists as functions (as in arc), and
    allow referring to undefined variables and calling undefined
    functions.

This idea is not ridiculous, but I am not convinced the benefits are
worth the cost.

Putting these changes in Emacs Lisp (as opposed to some new system)
could lead to bad incompatibility problems.  I am pretty sure there
are things that depend on the fact that "" and nil are different
objects.

To get much benefit from nil = 0, I think we would need t = 1.

    Arguing that some of these things are better or worse is wrong.  It
    doesn't make sense to reject unifying "" and `nil' on one hand and
    reject separating false and '() on the other -- *unless* it's clear
    that it's a subjective decision.

Both of these decisions are a matter of comparing advantages.
The advantages to be compared are different in the two cases,
so there is no reason to think they should be decided alike.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Steve Yegge]

[-- 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 --]

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

[Eli Zaretskii]

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

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

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

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

[Steve Yegge]

[-- 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 --]

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

[Drew Adams]

> I've decided that throwing errors on nil strings -- however
> good the intentions may have been -- is doing more harm than good.
...
> 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.

Just because "" and () are similar in some ways does not mean that they should
be treated as identical in general - any more than [] and () should be.  "For
all intents, just another nil" can apply to a lot of things, including 0 for
whole numbers.  Should we conclude also that throwing errors on nil numbers,
like "nil strings", does more harm than good?

No, you didn't make so general an argument - good.

You limited it to "all the core string-manipulation functions" (not very clear
to me), and even more specifically to "the smallest set of [core?] functions
that may originate the infamous `wrong-type-argument (stringp, nil)' error".

But that still quite general appeal wrt string type errors ("Throwing an error
on a nil string is a radical departure from the core philosophy.") was countered
by pointing out that sometimes it is TRT to raise such an error.

And you yourself said in the same breath that "Emacs libraries should already do
nil-checking on string arguments."  Surely they do, and in some cases they raise
an error as a consequence, and in some cases the only possible or the most
appropriate error is the one being decried.

As long as we discuss this at such a general level your argument will not go
far, I'm afraid.

So you say even more narrowly that there is a well-defined class of cases - a
"corner" where you feel that "" and () should be equated and raising an error is
wrong.  I fear that even this more constrained hand-waving is still unlikely to
cut the mustard, but if you nail it down clearly then maybe you can progress
with it.

If you are convinced that your argument is truly more general than what can be
dealt with case by case, and you can accurately identify the "very specific
corner of the type system" that merits such a change, then, by all means,
identify it rigorously and give supporting arguments.

IOW, be specific about your very specific corner.  Specify the problem and its
boundaries.

Barring that, I'd add my voice to the advice already given by others: handle any
particular functions that you feel ought to treat "" and () the same, but do not
yet do so, on a case-by-case basis.

Start with a specific function where you think it is bad design to distinguish
"" from () and to raise an error when () is encountered but "" was expected
(i.e., acceptable).  For that function, point to a specific problem - e.g. a
startup problem, since you refer to that.

IOW2, give specific arguments for each such function as to why it should equate
"" and ().  IOW3, identify the specific problems you've run into - file a bug,
for instance.

You are much more likely to have others see your light if you are specific and
clear.  In fact, if you had started with a specific bug report, it's quite
possible that others would themselves have made the same leap to your "corner",
assuming it is well-defined.

Finally, you say that the "real reason" for your quest is that if such an error
is raised at startup then a newbie's goose is nuked.  For that, I'm afraid, the
replique given already is the right one: recipe please.  It sounds like you or
someone you know has stumbled on a bug that needs fixing.  And that, I think, is
the place to start.  It is, after all, the real problem behind your real reason.

FWIW, I am sympathetic to the problem you describe.  I even filed a
(non-specific, no-recipe, not-very-useful) bug report a while back that could
perhaps be a poster child for the "worse" scenario you cite:

 "If Emacs can't start up, or (worse) it gets into one of
  those horrid scenarios where some hook is throwing an error
  on almost every command and preventing the user from doing
  anything useful, then you're no longer in Emacs.  You're in
  brokenville.  All the advantages and pleasure of Emacs as a
  dev environment have vanished."

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105

And yes, debugging that one (in particular, but perhaps it is not really so
particular) is not so simple.

But the good news is that I see this particular behavior _only_ in Emacs 24,
which is not yet released.  So your argument about developers vs users, even in
the narrow sense in which it might sometimes be appropriate, does not really
apply here.

The better news will be when the bug can be found and fixed.  But so far at
least I'm not convinced that your proposal is the right way to deal with this
case.  I'd sooner see it found and fixed than finessed.

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

[Steve Yegge]

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

This is nicely argued.

I've made the mistake of failing to record any information when I've
encountered
this specific error category that's been plaguing me.  We've got ~4000 Emacs
users at Google, and there is a core group of 20 or 30 folks who act as tech
support for the rest.  We've got a big net trolling along the bottom of the
ocean,
and we catch all sorts of unpleasant stuff, but we're just throwing it back
rather
than keeping records.  So I don't have a bunch of bug repro cases, nor
specific
code that would have been cleaner had the lower-level functions accepted
nil.

The most recent occurrence is relatively fresh:  I was observing some
annoying
behavior in a Google elisp library -- one that had been doing some path
manipulation
and choking on nil because, for whatever reason, `temporary-file-directory'
had
been bound to nil.  So I fixed up the Google function to handle nil the
same way
it handles the empty string.  And I glanced around and noticed that the same
hack had been applied all over the place, sometimes smoothed over with
macros
or what have you.  It was a lot of smoothing over what appears to be a core
wrinkle.

That said, it was just one example, and I have not kept good records -- in
part
because most Googlers are still on emacs 23, and I haven't wanted to file
bugs
until I can verify them in emacs24, which is more time than I've had to
allot to it.

I'm on emacs 24 now, and I'll be dutiful about it, but it's going to be
another year
or two at least before I'm able to respond to the demands for specific
examples.
But even then it seems unlikely that I'll report the majority of them,
because once
people start asking for hundreds of case-by-case justifications, the battle
is lost.
That's why I tried arguing it from the general case on the first go-round.

But no matter.  It was a thought experiment.  I've planted a seed, and maybe
in the coming years people will start evaluating any occurrences they may
encounter of errors on nil-valued string args.  In time we may have a
corpus of
evidence one way or the other.  If not, I'll eventually have a pile of
examples as
I begin keeping better records.

In the meantime, I very much like Stefan's argument to the effect that
patches
speak louder than words.  I'll patch my local copy and start playing with
it.

I also like his observation that nil-in-nil-out aids function composition.
Unfortunately, given that most of the arguments in this thread are focused
on
type assertions, it's unlikely that jumping on that bandwagon will turn the
tide.

In the shorter term, I hope to be able to get some concrete bug reports
around
emacs 24 startup behavior and/or library-loading behavior over the next few
months, now that more of us are using it.

-steve

On Fri, Apr 27, 2012 at 2:24 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > I've decided that throwing errors on nil strings -- however
> > good the intentions may have been -- is doing more harm than good.
> ...
> > 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.
>
> Just because "" and () are similar in some ways does not mean that they
> should
> be treated as identical in general - any more than [] and () should be.
>  "For
> all intents, just another nil" can apply to a lot of things, including 0
> for
> whole numbers.  Should we conclude also that throwing errors on nil
> numbers,
> like "nil strings", does more harm than good?
>
> No, you didn't make so general an argument - good.
>
> You limited it to "all the core string-manipulation functions" (not very
> clear
> to me), and even more specifically to "the smallest set of [core?]
> functions
> that may originate the infamous `wrong-type-argument (stringp, nil)'
> error".
>
> But that still quite general appeal wrt string type errors ("Throwing an
> error
> on a nil string is a radical departure from the core philosophy.") was
> countered
> by pointing out that sometimes it is TRT to raise such an error.
>
> And you yourself said in the same breath that "Emacs libraries should
> already do
> nil-checking on string arguments."  Surely they do, and in some cases they
> raise
> an error as a consequence, and in some cases the only possible or the most
> appropriate error is the one being decried.
>
> As long as we discuss this at such a general level your argument will not
> go
> far, I'm afraid.
>
> So you say even more narrowly that there is a well-defined class of cases
> - a
> "corner" where you feel that "" and () should be equated and raising an
> error is
> wrong.  I fear that even this more constrained hand-waving is still
> unlikely to
> cut the mustard, but if you nail it down clearly then maybe you can
> progress
> with it.
>
> If you are convinced that your argument is truly more general than what
> can be
> dealt with case by case, and you can accurately identify the "very specific
> corner of the type system" that merits such a change, then, by all means,
> identify it rigorously and give supporting arguments.
>
> IOW, be specific about your very specific corner.  Specify the problem and
> its
> boundaries.
>
> Barring that, I'd add my voice to the advice already given by others:
> handle any
> particular functions that you feel ought to treat "" and () the same, but
> do not
> yet do so, on a case-by-case basis.
>
> Start with a specific function where you think it is bad design to
> distinguish
> "" from () and to raise an error when () is encountered but "" was expected
> (i.e., acceptable).  For that function, point to a specific problem - e.g.
> a
> startup problem, since you refer to that.
>
> IOW2, give specific arguments for each such function as to why it should
> equate
> "" and ().  IOW3, identify the specific problems you've run into - file a
> bug,
> for instance.
>
> You are much more likely to have others see your light if you are specific
> and
> clear.  In fact, if you had started with a specific bug report, it's quite
> possible that others would themselves have made the same leap to your
> "corner",
> assuming it is well-defined.
>
> Finally, you say that the "real reason" for your quest is that if such an
> error
> is raised at startup then a newbie's goose is nuked.  For that, I'm
> afraid, the
> replique given already is the right one: recipe please.  It sounds like
> you or
> someone you know has stumbled on a bug that needs fixing.  And that, I
> think, is
> the place to start.  It is, after all, the real problem behind your real
> reason.
>
> FWIW, I am sympathetic to the problem you describe.  I even filed a
> (non-specific, no-recipe, not-very-useful) bug report a while back that
> could
> perhaps be a poster child for the "worse" scenario you cite:
>
>  "If Emacs can't start up, or (worse) it gets into one of
>  those horrid scenarios where some hook is throwing an error
>  on almost every command and preventing the user from doing
>  anything useful, then you're no longer in Emacs.  You're in
>  brokenville.  All the advantages and pleasure of Emacs as a
>  dev environment have vanished."
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105
>
> And yes, debugging that one (in particular, but perhaps it is not really so
> particular) is not so simple.
>
> But the good news is that I see this particular behavior _only_ in Emacs
> 24,
> which is not yet released.  So your argument about developers vs users,
> even in
> the narrow sense in which it might sometimes be appropriate, does not
> really
> apply here.
>
> The better news will be when the bug can be found and fixed.  But so far at
> least I'm not convinced that your proposal is the right way to deal with
> this
> case.  I'd sooner see it found and fixed than finessed.
>
>

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

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

[Andreas Schwab]

Steve Yegge <steve.yegge@gmail.com> writes:

> The most recent occurrence is relatively fresh:  I was observing some
> annoying
> behavior in a Google elisp library -- one that had been doing some path
> manipulation
> and choking on nil because, for whatever reason, `temporary-file-directory'
> had
> been bound to nil.  So I fixed up the Google function to handle nil the
> same way
> it handles the empty string.  And I glanced around and noticed that the same
> hack had been applied all over the place, sometimes smoothed over with
> macros
> or what have you.  It was a lot of smoothing over what appears to be a core
> wrinkle.

I see many places that check if temporary-file-directory is bound at
all, but none that special cases a value of nil.  This is just to
support Emacs before 20.3 where the variable didn't exist yet.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Odd formatting (was: proposal to make null string handling more emacs-y)

[Lars Magne Ingebrigtsen]

Steve Yegge <steve.yegge@gmail.com> writes:

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

Totally off topic, I was looking at how strange your messages are
rendering and wondering whether the mail reader was interpreting your
messages incorrectly or something.  But here's the (sort of) raw source
of that text:

<div>I agree with you. Fortunately that&#39;s not what I&#39;m arguing. I&#39;m arguing that</div><div>for a very specific corner of the type system, we merge two separate</div>
<div>meanings of nil. I&#39;m arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div>

(This is the text/html part of the multipart message you send.)

So your mail reader is wrapping (apparently) random parts of the text in
<div> section, and <div> section are rendered by shr.el as a block-level
elements (which is quite normal, I think).

You're posting through Gmail, so I expect to see a lot more of this kind
of stuff in the future.

Does anybody know why Gmail is doing this, and what shr should be doing
to this, er, stuff to render it properly?  I can't see any hints in the
source of the message that these <div>s are supposed to be
non-block-level elements, but perhaps I'm missing something...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Odd formatting

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Totally off topic, I was looking at how strange your messages are
> rendering and wondering whether the mail reader was interpreting your
> messages incorrectly or something.  But here's the (sort of) raw source
> of that text:

> <div>I agree with you. Fortunately that&#39;s not what I&#39;m arguing. I&#39;m arguing that</div><div>for a very specific corner of the type system, we merge two separate</div>
> <div>meanings of nil. I&#39;m arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div>

> (This is the text/html part of the multipart message you send.)

Note that the text/plain version of the message is foramatted exactly
like the bit you quoted.

Re: Odd formatting

[Antoine Levitt]

30/04/12 09:48, Steinar Bang
>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>
>> Totally off topic, I was looking at how strange your messages are
>> rendering and wondering whether the mail reader was interpreting your
>> messages incorrectly or something.  But here's the (sort of) raw source
>> of that text:
>
>> <div>I agree with you. Fortunately that&#39;s not what I&#39;m arguing. I&#39;m arguing that</div><div>for a very specific corner of the type system, we merge two separate</div>
>> <div>meanings of nil. I&#39;m arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div>
>
>> (This is the text/html part of the multipart message you send.)
>
> Note that the text/plain version of the message is foramatted exactly
> like the bit you quoted.

Looks like he's writing his email in emacs, with emacs wrapping, and
then pasting it into gmail, which then adds further (and different)
wrapping. Not much gnus can do, I think.

Re: Odd formatting

[Nix]

On 30 Apr 2012, Antoine Levitt uttered the following:

> 30/04/12 09:48, Steinar Bang
>>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>>
>>> Totally off topic, I was looking at how strange your messages are
>>> rendering and wondering whether the mail reader was interpreting your
>>> messages incorrectly or something.  But here's the (sort of) raw source
>>> of that text:
>>
>>> <div>I agree with you. Fortunately that&#39;s not what I&#39;m arguing. I&#39;m arguing that</div><div>for a very specific corner of the type system, we merge two separate</div>
>>> <div>meanings of nil. I&#39;m arguing that the empty string as it is used today is,</div><div>for all intents, just another nil. So it should not signal an error if they are</div><div>treated the same.</div>
>>
>>> (This is the text/html part of the multipart message you send.)
>>
>> Note that the text/plain version of the message is foramatted exactly
>> like the bit you quoted.
>
> Looks like he's writing his email in emacs, with emacs wrapping, and
> then pasting it into gmail, which then adds further (and different)
> wrapping. Not much gnus can do, I think.

Yeah. I suspect the Emacs wrapping is considered hard returns, and gmail
is adding further soft returns on top of that, and then expressing each
hard return as a <div>. Solution, "don't do that then", since I doubt
there is a way to turn off wrapping in gmail or to get it to stop
treating each explicitly-entered RET as a <div>.

-- 
NULL && (void)

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

[Stefan Monnier]

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

Most of the time throwing an `error' doesn't prevent the user from
getting his job done.  E.g. it doesn't "crash" Emacs.  And while the
user may not be able to debug it himself, he is able to get a backtrace
and send it to us, whereas with a more permissive semantics, you don't
get anything, so fixing the problem will require more interactions with
the user.

IOW, I think the problem is when an error makes Emacs unusable, and we
should focus on this (which is typically an issue that's not dependent
on the kind of error signaled, but the context where it's signaled).

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

I have no big fear about your proposal.  I expect it won't make
much difference.

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

I don't expect any change you suggested would bring a significant number
of bugs.  The only downside I mention is that it might hide some bugs
(which would have existed regardless of that change) and make them more
difficult to track down and fix.
Of course, maybe it will also fix some bugs.   And maybe it will also
allow us to simplify some Lisp code.

I general I like the idea of treating lists and vectors uniformly, and
strings are one particular kind of vector.  But Emacs is a conservative
system, so changes have to go slow.  Send us a patch that covers the
most obviously beneficial cases (ideally with some code cleanup made
possible by the new semantics),


        Stefan

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

[Lars Magne Ingebrigtsen]

Steve Yegge <steve.yegge@gmail.com> writes:

> I think we should change all the core string-manipulation functions to
> deal gracefully with nil arguments.

I think it's an intriguing idea.

Let's look at some not-quite-real bits of code.  We get a string from a
map, and then, if it exists, we want to insert it twice, capitalised.

Because `capitalize' bugs out on a nil parameter, this is how we do it
today:

(let ((foo (plist-get map 'foo)))
  (when foo
    (setq foo (capitalize foo))
    (insert foo)
    ...
    (insert foo)))

The "problem" here being the dreaded `setq'.  For reading comprehension,
its nice to not mutate variables.  If we instead allowed `capitalize' to
take a nil parameter, we'd have the more readable

(let ((foo (capitalize (plist-get map 'foo))))
  (when foo
    (insert foo)
    ...
    (insert foo)))

And we can get away with a much more functional style if we allowed
`insert' to take nil as a parameter (meaning "insert nothing"):

(insert (capitalize (plist-get map 'foo)))

instead of 

(let ((foo (plist-get map 'foo)))
  (when foo
    (insert (capitalize foo))))

I also often see code like (well, the equivalent of)

(let ((foo (capitalize (or (plist-get map 'foo) ""))))
  ...)

to avoid all the checking and `setq'-ing, but this makes the code less
clear, and you end up with nonsensical tests like `(zerop (length foo))'
later in the code if you really need to check whether you had a `foo'
there anyway.

I don't really see much of a downside to allowing (many) stringey
functions to take nil as a parameter.  And there's an upside.  So why
not?
    
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Andreas Röhler]

Am 25.04.2012 02:24, schrieb Steve Yegge:
> (string= nil "")

what's strange for me in context:


(if ""
     (message "%s" "empty string proved true")
       (message "%s" "empty string proved false"))

==> "empty string proved true"

Andreas

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

[Drew Adams]

> > (string= nil "")
> 
> (if ""
>      (message "%s" "empty string proved true")
>        (message "%s" "empty string proved false"))
> ==> "empty string proved true"

"" is not equal or eq or eql to nil.
But "" is string= to nil.

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

[Andreas Röhler]

Am 29.04.2012 19:08, schrieb Drew Adams:
>>> (string= nil "")
>>
>> (if ""
>>       (message "%s" "empty string proved true")
>>         (message "%s" "empty string proved false"))
>> ==>  "empty string proved true"
>
> "" is not equal or eq or eql to nil.
> But "" is string= to nil.
>
>

in other words said:

if the empty list is nil, why the empty string should yield true?

for me

(equal nil "")==> t

would be plausible

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

[Drew Adams]

> if the empty list is nil, why the empty string
> should yield true?  for me (equal nil "")==> t
> would be plausible

Seeing a new patch of sky, our worm has designs of wiggling its way out of the
almost open can...  But "" is a very short worm, and it has a long way to
wiggle...

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

[PJ Weisberg]

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

On Sunday, April 29, 2012, Andreas Röhler <andreas.roehler@online.de> wrote:
> Am 29.04.2012 19:08, schrieb Drew Adams:
>>>>
>>>> (string= nil "")
>>>
>>> (if ""
>>>      (message "%s" "empty string proved true")
>>>        (message "%s" "empty string proved false"))
>>> ==>  "empty string proved true"
>>
>> "" is not equal or eq or eql to nil.
>> But "" is string= to nil.
>>
>>
>
> in other words said:
>
> if the empty list is nil, why the empty string should yield true?
>
> for me
>
> (equal nil "")==> t
>
> would be plausible

Think of it as converting nil to a string when necessary.  `string='
requires strings, so nil is treated as "".  `equal' doesn't require
strings, so nil is treated as nil.

-- 
-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

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