Re: Rationale for split-string?

[Stephen J. Turnbull]

    >   (split-string ",,data,," ",")
    > => ("" "data" "")

    rms> Is that wrong?  If so, what result do you think is right?
    rms> ("" "" "data" "" "") could be argued for, but I am not sure
    rms> it is better.

Well, if you are parsing a comma separated value file (the standard
text/plain output format for spreadsheets and some databases, such as
subversion), the five-element list is exactly what you want, and the
three-element list is a type error (incomplete record).  In what case
would the three-element list be desirable?  I understand the case for
a one-element result, but not three.

I see basically two modes.  In one mode you are parsing fields from
each of a sequence of records, in which case you want to retain null
strings as null values.  In the other, you are parsing a (free-form)
stream of words, in which case null words (usually) don't exist, so
you want to throw away _all_ of the null strings.  In fact, all of the
whitespace-only strings, too, but those normally won't arise in the
common case where SEPARATORS matches contiguous whitespace.

I think we should support both modes, but the token-parser is easy to
derive from the field-parser, while it's impossible to do the reverse
because the token parser throws away information.  I conclude that the
field-parser (the XEmacs behavior) is more primitive, and I'd like to
call that `split-string', with either more sophisticated behavior
implemented by overloading the separators argument to take keywords
for special treatment, or (preferably) in a separate function.


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