References: <F7B85C69-6ECE-459F-95F4-27C821AB86FA@seanallred.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
            Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Message-ID:  <55B34C0E.2070606@morningstar2.co.uk>
Date:         Sat, 25 Jul 2015 09:42:54 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: expl3 and input parsing
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <F7B85C69-6ECE-459F-95F4-27C821AB86FA@seanallred.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

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