Re: Rationale for split-string?

[Richard Stallman]

    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 that makes sense.  Does anyone see a counterargument,
or a reason why any other behavior is useful?

    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', 

I don't entirely agree.  The default case uses strings of whitespace
as the separator, and for that case, the only intelligent approach is
token-parsing.  So the function needs to be able to do token-parsing.
This feature therefore may as well also be available for any separator.