MIME-Version: 1.0
References: <F7B85C69-6ECE-459F-95F4-27C821AB86FA@seanallred.com>
            <55B34C0E.2070606@morningstar2.co.uk>
Content-Type: multipart/alternative; boundary=001a114db35216af94051cb8ecbc
Message-ID:  <CABceR4aAp8bNKi7CYBsivXbnOWYx2iVFp=A8Es1jDvt=s-JXzA@mail.gmail.com>
Date:         Fri, 7 Aug 2015 13:50:34 +0000
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: Sean Allred <allred.sean@GMAIL.COM>
Subject: Re: expl3 and input parsing
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <55B34C0E.2070606@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

--001a114db35216af94051cb8ecbc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <
joseph.wright@morningstar2.co.uk> wrote:

> On 03/07/2015 02:29, Sean Allred wrote:
> > Hello all,
> >
> > Long story short, I=E2=80=99ve written a general parser for the
> >
> >     key: type [=3D default], [=E2=80=A6]
> >
> > 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=E2=80=99ve named the function \parse_dictionar=
y:nn,
> which takes the input as #1 and the parsing logic as #2:
> >
> >     \parse_dictionary:nn
> >       {
> >         key-1: type-1 =3D default-1,
> >         key-2: type-2 =3D 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 =E2=80=98parsing=E2=80=99=
 module, or
> should this be relegated to a separate expl3 module (like termmenu,
> lt3graph, etc.)? This I ask because, from my perspective, the kernel tend=
s
> toward pure programming and low-level typesetting (from a =E2=80=98physic=
al world=E2=80=99
> perspective; i.e. doing what l3coffin does in the real world isn=E2=80=99=
t that
> difficult, but convincing TeX to do it is nothing short of a world-wonder=
).
> Input parsing doesn=E2=80=99t really fit that scope. On the other hand, s=
eparate
> 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 =E2=80=94 I don=E2=80=99t think compl=
ex 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
>

--001a114db35216af94051cb8ecbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sounds good :) I&#39;ll just make this a separate module w=
hen life slows down again.<div><br></div><div>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 \Re=
quirePackage{expl3} is pretty straightforward, but how does this thought ap=
ply to pure expl3 modules? Should it be assumed that expl3 is loaded?</div>=
<div><br></div><div>My initial thought is that it must -- LaTeX2e packages =
don&#39;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 b=
ack to the chasm of &#39;how LaTeX3 will be invoked&#39;.</div><div><br></d=
iv><div>Best,</div><div>Sean</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr">On Sat, Jul 25, 2015 at 3:45 AM Joseph Wright &lt;<a href=3D"m=
ailto:joseph.wright@morningstar2.co.uk">joseph.wright@morningstar2.co.uk</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/07/2015 02:29, S=
ean Allred wrote:<br>
&gt; Hello all,<br>
&gt;<br>
&gt; Long story short, I=E2=80=99ve written a general parser for the<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0key: type [=3D default], [=E2=80=A6]<br>
&gt;<br>
&gt; format that xtemplate uses. Since this seems to be what at least LaTeX=
3 is heading toward, I wrote the parser so that it could be applied to a mu=
ltitude of situations (even xtemplate itself, I think). In a sense, it is g=
eneric in that it can handle any input of this type, but is specialized *to=
 this type* of input. I=E2=80=99ve named the function \parse_dictionary:nn,=
 which takes the input as #1 and the parsing logic as #2:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0\parse_dictionary:nn<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key-1: type-1 =3D default-1,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key-2: type-2 =3D default-2,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\tl_show:N \l_parse_dictionary_key_tl=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\tl_show:N \l_parse_dictionary_type_t=
l<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\tl_show:N \l_parse_dictionary_value_=
tl<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
<br>
We are pretty sure xtemplate is &#39;wrong&#39;. Parsing more generally may=
 or<br>
may not be useful, but I think at this stage it&#39;s best not to add this<=
br>
to the kernel. I&#39;m mindful of the need to tackle &#39;big issues&#39; a=
nd we<br>
already have quite a list :-)<br>
<br>
&gt; Does the kernel have philosophical room for a =E2=80=98parsing=E2=80=
=99 module, or should this be relegated to a separate expl3 module (like te=
rmmenu, lt3graph, etc.)? This I ask because, from my perspective, the kerne=
l tends toward pure programming and low-level typesetting (from a =E2=80=98=
physical world=E2=80=99 perspective; i.e. doing what l3coffin does in the r=
eal world isn=E2=80=99t that difficult, but convincing TeX to do it is noth=
ing short of a world-wonder). Input parsing doesn=E2=80=99t 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 s=
uspect this is just a misunderstanding on my part, though =E2=80=94 I don=
=E2=80=99t think complex input parsing should be a part of the core expl3 l=
anguage.<br>
<br>
Important note: the aim is that all functionality will have a code level<br=
>
interface from which higher-level constructs will be built.<br>
--<br>
Joseph Wright<br>
</blockquote></div>

--001a114db35216af94051cb8ecbc--