Long story short, I’ve written a general parser for the
key: type [= default], […]
format that xtemplate uses. Since this seems to be what at least LaTeX3 is heading toward, I wrote the parser so that it could be applied to a multitude of situations (even xtemplate itself, I think). In a sense, it is generic in that it can handle any input of this type, but is specialized *to this type* of input. I’ve named the function \parse_dictionary:nn, which takes the input as #1 and the parsing logic as #2:
\parse_dictionary:nn
{
key-1: type-1 = default-1,
key-2: type-2 = default-2,
}
{
\tl_show:N \l_parse_dictionary_key_tl
\tl_show:N \l_parse_dictionary_type_tl
\tl_show:N \l_parse_dictionary_value_tl
}
Does the kernel have philosophical room for a ‘parsing’ module, or should this be relegated to a separate expl3 module (like termmenu, lt3graph, etc.)? This I ask because, from my perspective, the kernel tends toward pure programming and low-level typesetting (from a ‘physical world’ perspective; i.e. doing what l3coffin does in the real world isn’t that difficult, but convincing TeX to do it is nothing short of a world-wonder). Input parsing doesn’t really fit that scope. On the other hand, separate talks of what l3color will be (someday) make it seem like such functionality would prove useful in the kernel. I suspect this is just a misunderstanding on my part, though — I don’t think complex input parsing should be a part of the core expl3 language.
Aside, I can’t think of any more member functions for such a module off the top of my head, but it seems silly to have a one-function module. Is there a better way to go about organizing this?
All the best,
Sean Allred