unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: stephen@xemacs.org, emacs-devel@gnu.org,
	xemacs-design@xemacs.org, rms@gnu.org
Subject: Re: Rationale for split-string?
Date: Mon, 21 Apr 2003 22:26:01 -0500 (CDT)	[thread overview]
Message-ID: <200304220326.h3M3Q1912252@eel.dms.auburn.edu> (raw)
In-Reply-To: <20030421234347.GA12507@gnu.org> (message from Miles Bader on Mon, 21 Apr 2003 19:43:47 -0400)

Miles Bader wrote:

   I think Stephen's formulation is very natural, in that you usually
   want OMIT-NULLS to be t if you're splitting on a non-whitespace
   string.

First of all, I am not worried about Stephen's formulation being
unnatural (although the original formulation actually would produce
unnatural results in the default case), but about it breaking existing
code.

I believe you are underestimating the level of generality of
split-string and the wild heterogeneity of its applications.  It is by
no means whatsoever true that except in the whitespace case you would
want to keep all null matches.  If SEPARATORS is a "terminator
character", say newline, then a null match at the beginning counts.
There is no reason you would start the string with a terminator other
than to explicitly terminate an empty string.  The empty match at the
end does not count, because the terminator at that place just
terminates the previous match.  This is, for instance, how you would
want to split a buffer, or a file, or user input, into lines.  The way
you implement that with the current split-string is to first check for
an initial terminator and, if there is one, prepend an empty string to
the split-string output.  With the proposed new split-string, you
delete the empty match at the end from the split-string output.  That
is actually easier.  However...

The "however" is that we are not defining a *new* function but
*re*defining an *existing* function, an often used and extremely
general existing function.  That is all but guaranteed to produce a
wild variety of bugs.

In fact let us assume, for the sake of argument, that Stephen and you
are 100% right.  That would mean that any correct existing code, using
the present Emacs split-string with a non-nil SEPARATORS, checks for
empty matches at the beginning and end and adds any such matches to
the split-string output to correct the "bug" in the present
split-string.  After Stephen's change, any empty match at the
beginning and end of the string will produce not one, but two empty
strings.

Sincerely,

Luc.



  reply	other threads:[~2003-04-22  3:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17  9:06 Rationale for split-string? Stephen J. Turnbull
2003-04-17 11:30 ` Stefan Reichör
2003-04-18  1:54   ` Richard Stallman
2003-04-18  2:59     ` Steve Youngs
2003-04-17 17:44 ` Stefan Monnier
2003-04-17 19:32   ` Luc Teirlinck
2003-04-18 11:50   ` Stephen J. Turnbull
2003-04-18 14:17     ` Stefan Monnier
2003-04-19  8:18       ` Stephen J. Turnbull
2003-04-19 13:35     ` Richard Stallman
2003-04-19  4:14   ` Richard Stallman
2003-04-19  8:55     ` Stephen J. Turnbull
2003-04-21  0:59       ` Richard Stallman
2003-04-21  1:55         ` Luc Teirlinck
2003-04-21 10:58         ` Stephen J. Turnbull
2003-04-21 21:11           ` Luc Teirlinck
2003-04-21 23:43             ` Miles Bader
2003-04-22  3:26               ` Luc Teirlinck [this message]
2003-04-22  4:09                 ` Jerry James
2003-04-22  8:15                   ` Eli Zaretskii
2003-04-22 13:22                     ` Stephen J. Turnbull
2003-04-22 14:38                       ` Jerry James
2003-04-22 12:56                   ` Luc Teirlinck
2003-04-22 14:56                     ` Jerry James
2003-04-22 15:27                       ` Luc Teirlinck
2003-04-22 13:19                 ` Stephen J. Turnbull
2003-04-22 13:39                   ` Miles Bader
2003-04-22 13:51                   ` Luc Teirlinck
2003-04-22 16:26                   ` Luc Teirlinck
2003-04-23  1:00           ` Richard Stallman
2003-04-23  4:09             ` Stephen J. Turnbull
2003-04-24 23:12               ` Richard Stallman
2003-05-20  1:55               ` Stephen J. Turnbull
2003-05-22 15:00                 ` Kai Großjohann
  -- strict thread matches above, loose matches on Subject: below --
2003-05-20  3:11 Bill Wohler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200304220326.h3M3Q1912252@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=stephen@xemacs.org \
    --cc=xemacs-design@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).