Will Robertson wrote:
> The other point of view is that we should allow some flexibility in how
> users may end up needing to input list-like data, and providing a range
> of delimited list types will be more convenient for (a)
> multi-dimensional lists such as used by mlist, and (b) not having to
> escape the delimiting characters as much; say if the list is likely to
> contain commas then you can delimit it with vertical bars instead.
> 
> I lean towards the second philosophy. My tentative proposal is to rename
> the clist module to, er, something else, and for it to generalise the
> functions in clist such that functions for new "delimiter"-lists can be
> instantiated with a single command.
> 
> I.e., the hypothetical command
>   \def_delimiter_list:nn {clist} {,}
> would generate the suite of functions that are currently defined in
> l3clist;
>   \def_delimiter_list:nn {slist} {;}
> might then define equivalent commands for dealing with semi-colon
> delimited lists.

If we take your two cases, lets imagine two modules both of which define
new list types.  How do you handle the various possibilities:
1) They choose different prefixes and different delimiters;
2) They choose different prefixes and the same delimiter;
3) They choose the same prefix and different delimiters;
4) They choose the same prefix and the same delimiter?

Also, each of these would have to create a lot of (possibly pointless)
functions.

On a completely different level, looking at an example definition:

\def_long_test_function_new:npn {clist_if_in:Nn} #1#2 {
  \def_long:Npn \tmp:w ##1,#2,##2##3 \q_stop {
    \reverse_if:N \if_meaning:NN \q_no_value ##2
  }
  \exp_after:NN \tmp:w \exp_after:NN , #1, #2, \q_no_value \q_stop
}

Things get much more spaghetti-like very quickly if this needs to be
done with a variable delimiter.  Not a show-stopper, of course, but I'm
not sure such a great idea either.

> Alternatively, maybe I'm taking this way too far and all we need is a
> generalised mapping function that can loop through a token list using an
> arbitrary substring as a delimiter. That would probably cover the
> majority of the cases that \def_delimiter_list would be useful for.

This fits it with what Paul has said in his reply (a general "string"
module, perhaps).

I'd favour sticking with just comma lists (by far the most common type),
and providing the arbitrary function you describe.  While LaTeX3 is
supposed to have a good programming base, I'd expect that the
specialised ideas you suggest are rare enough that they can be handled
at a module level, not in the kernel.

Joseph