Sounds good :) I'll just make this a separate module when life slows down
again.

That being the case, is there any recommendation for how to structure
external expl3 modules (other than the name-formats of the control
sequences defined)? While they use expl3, things like siunitx and
chemmacros are proper LaTeX packages and so the \RequirePackage{expl3} is
pretty straightforward, but how does this thought apply to pure expl3
modules? Should it be assumed that expl3 is loaded?

My initial thought is that it must -- LaTeX2e packages don't load the
kernel (though they do test for a minimum version of it). If LaTeX3 is
loaded, of course expl3 will be -- but I suppose this goes back to the
chasm of 'how LaTeX3 will be invoked'.

Best,
Sean

On Sat, Jul 25, 2015 at 3:45 AM Joseph Wright <
[log in to unmask]> wrote:

> On 03/07/2015 02:29, Sean Allred wrote:
> > Hello all,
> >
> > 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
> >       }
>
> We are pretty sure xtemplate is 'wrong'. Parsing more generally may or
> may not be useful, but I think at this stage it's best not to add this
> to the kernel. I'm mindful of the need to tackle 'big issues' and we
> already have quite a list :-)
>
> > 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.
>
> Important note: the aim is that all functionality will have a code level
> interface from which higher-level constructs will be built.
> --
> Joseph Wright
>