emacs-devel
[Top][All Lists]
Advanced

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

Rationale for split-string?


From: Stephen J. Turnbull
Subject: Rationale for split-string?
Date: Thu, 17 Apr 2003 18:06:17 +0900
User-agent: Gnus/5.090016 (Oort Gnus v0.16) XEmacs/21.5 (cabbage)

What is the rationale for the specification of `split-string'?

That is, in GNU Emacs

  ;; an often convenient abbreviation
  (split-string "  data  ")
=> ("data")

  ;; weird
  (split-string "  data  " " ")
=> ("" "data" "")

  ;; urk (think "gnumeric just-say-no.xls" "save as" "csv")
  (split-string ",,data,," ",")
=> ("" "data" "")

emacs-version
"21.2.2"

In XEmacs currently we get

  ;; usually (delete "" (split-string "  data  ")) should do the
  ;; trick if you don't like this
  (split-string "  data  ")
=> ("" "data" "")

  ;; no less useful than what GNU Emacs returns
  (split-string "  data  " " ")
=> ("" "" "data" "" "")

  ;; I can't imagine wanting anything else
  (split-string ",,data,," ",")
=> ("" "" "data" "" "")

For comparison, Python's `split' function behaves like XEmacs's
`split-string'.  Perl's `split' function by default removes all trailing
null fields while preserving all leading null fields, but when invoked
"split (/pattern/, string, -1)" behaves like XEmacs's `split-string'.

I think it makes sense for GNU Emacs to adopt (return to?) the
simpler, more consistent behavior, rather than have XEmacs sync to GNU
Emacs.  In particular, I think it's really unfortunate to force people
who want to parse csv data and the like to write their own functions,
while the `(delete "" (split-string ...))' idiom not only seems very
natural to me, but it handles the second example better than GNU Emacs
currently does.  And while I'm sure there exist applications where
trimming null fields at the ends but leaving them when surrounded by
non-null ones make sense, I can't come up with one offhand.  I suspect
they're less common than either "remove all nulls" or "keep all nulls".

I believe that (at least for third-party maintainers) this change
should cause no problems, because we have had no complaints about the
behavior from anyone.  (We discovered the difference only when Ben
started a sync, and the regression test sent up flares and alarums.)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.




reply via email to

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