MIME-Version: 1.0
References: <CAFUtaNEDNgmniEKBn5Oe8=+S2PiZTe7=1HK7XQLq0cq0e8iu-g@mail.gmail.com>
            <CANQYN6xOonzhCqc34MrGqNouVbvdXOshkLxjbpkSrqSzwMGG6Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary=089e013d1dc6ebe7a904e10bbc6f
Message-ID:  <CAFUtaNHj4YpS2kRn5OEyf1CLftNA7ZtaVfb698PsBYCLfJHCbg@mail.gmail.com>
Date:         Mon, 8 Jul 2013 23:27:16 -0400
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: "Joel C. Salomon" <joelcsalomon@GMAIL.COM>
Subject: Re: Named options/enumerations (Was re: Defining \bool_case:nn)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CANQYN6xOonzhCqc34MrGqNouVbvdXOshkLxjbpkSrqSzwMGG6Q@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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

On Jul 8, 2013 10:33 PM, "Bruno Le Floch" <blflatex@gmail.com> wrote:
>
> Hello Joel,
>
> Surely Joseph will have something to say about the topic (he is
> currently doing some changes to l3keys), but let me try.

I've seen some of the changes already on GitHub, and they look like they'll
make life simpler.

> > This use of named options feels like it should be reasonably common in
> > user-facing code, but Expl3 doesn=E2=80=99t have an obvious way of mana=
ging
this.
> >
> >     \keys_define:nn { jcsfonts }
> >       { font .choice_code:n =3D \tl_gset:NV \g_jcsfonts_option_tl
> > \l_keys_choice_tl }
> >
> >     \str_case:Vnn \g_jcsfonts_option_tl
> >       { { cmodern } {} % Computer Modern is LaTeX default
> >         { kpfonts } { \RequirePackage{kpfonts} }
> >       } { \msg_error=E2=80=A6 }
>
> What about
>
>     \keys_define:nn { jcsfonts }
>       {
>         font .choice: ,
>         font / cmodern .code:n =3D { } ,
>         font / kpfonts .code:n =3D { \RequirePackage{kpfonts} } ,
>       }
>
> This will trigger a "key-choice-unknown" error upon encountering an
> unknown choice (well, right now the message is not defined... that'll
> be fixed).  Maybe we could add a feature to allow arbitrary code for
> unknown choices.

The code in the various options is more than a single line =E2=80=94 about =
ten
lines per option, actually, and it seems messy to intertwine option
processing with option execution like that.

> > I recently asked =E2=80=9CCan I refer to key value in general code?=E2=
=80=9D (
> > http://tex.stackexchange.com/q/120258/2966). My initial thought
(somewhat
> > bizarre, I=E2=80=99ll admit) was to save the option is a quark, set equ=
al to
one of
> > a group of quarks.
>
> I think that code was missing at least one "_".  Does my answer there
help you?

I didn't get a chance to look at it closely, but the basic idea of
combining property lists and key options feels =E2=80=9Cright", and would p=
rovide
the decoupling I'm looking for.

> I don't really get the issue with \str_case:Vnn, to be honest, and I
> don't see the advantage of an enum type.  Given that it makes the
> syntax much more verbose, I am so far not convinced.
<snip>
> An enum type seems to only be useful if it is significantly more
> efficient than a property list ("associative array"/"dictionary") with
> empty values.

I'm not fixated on enumerations, but I don't see how a property list is at
all the same thing. A enum object is one that can only take one of a
restricted list of values; in C it's basically a thinly-disguised integer,
combined with a list of integer constants. In expl3 it could be integers or
quarks (as in my bizarre idea above), whichever works better. (Or neither,
if the need for such a type is not there.)

Could you please explain what you meant?

=E2=80=94Joel

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

<p>On Jul 8, 2013 10:33 PM, &quot;Bruno Le Floch&quot; &lt;<a href=3D"mailt=
o:blflatex@gmail.com">blflatex@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hello Joel,<br>
&gt;<br>
&gt; Surely Joseph will have something to say about the topic (he is<br>
&gt; currently doing some changes to l3keys), but let me try.<br></p>
<p>I&#39;ve seen some of the changes already on GitHub, and they look like =
they&#39;ll make life simpler.</p>
<p>&gt; &gt; This use of named options feels like it should be reasonably c=
ommon in<br>
&gt; &gt; user-facing code, but Expl3 doesn=E2=80=99t have an obvious way o=
f managing this.<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 \keys_define:nn { jcsfonts }<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 { font .choice_code:n =3D \tl_gset:NV \g_jcs=
fonts_option_tl<br>
&gt; &gt; \l_keys_choice_tl }<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0 \str_case:Vnn \g_jcsfonts_option_tl<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 { { cmodern } {} % Computer Modern is LaTeX =
default<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 { kpfonts } { \RequirePackage{kpfonts=
} }<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 } { \msg_error=E2=80=A6 }<br>
&gt;<br>
&gt; What about<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 \keys_define:nn { jcsfonts }<br>
&gt; =C2=A0 =C2=A0 =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 font .choice: ,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 font / cmodern .code:n =3D { } ,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 font / kpfonts .code:n =3D { \RequirePacka=
ge{kpfonts} } ,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; This will trigger a &quot;key-choice-unknown&quot; error upon encounte=
ring an<br>
&gt; unknown choice (well, right now the message is not defined... that&#39=
;ll<br>
&gt; be fixed). =C2=A0Maybe we could add a feature to allow arbitrary code =
for<br>
&gt; unknown choices.</p>
<p>The code in the various options is more than a single line =E2=80=94 abo=
ut ten lines per option, actually, and it seems messy to intertwine option =
processing with option execution like that.</p>
<p>&gt; &gt; I recently asked =E2=80=9CCan I refer to key value in general =
code?=E2=80=9D (<br>
&gt; &gt; <a href=3D"http://tex.stackexchange.com/q/120258/2966">http://tex=
.stackexchange.com/q/120258/2966</a>). My initial thought (somewhat<br>
&gt; &gt; bizarre, I=E2=80=99ll admit) was to save the option is a quark, s=
et equal to one of<br>
&gt; &gt; a group of quarks.<br>
&gt;<br>
&gt; I think that code was missing at least one &quot;_&quot;. =C2=A0Does m=
y answer there help you?</p>
<p>I didn&#39;t get a chance to look at it closely, but the basic idea of c=
ombining property lists and key options feels =E2=80=9Cright&quot;, and wou=
ld provide the decoupling I&#39;m looking for.</p>
<p>&gt; I don&#39;t really get the issue with \str_case:Vnn, to be honest, =
and I<br>
&gt; don&#39;t see the advantage of an enum type. =C2=A0Given that it makes=
 the<br>
&gt; syntax much more verbose, I am so far not convinced.<br>
&lt;snip&gt;<br>
&gt; An enum type seems to only be useful if it is significantly more<br>
&gt; efficient than a property list (&quot;associative array&quot;/&quot;di=
ctionary&quot;) with<br>
&gt; empty values.</p>
<p>I&#39;m not fixated on enumerations, but I don&#39;t see how a property =
list is at all the same thing. A enum object is one that can only take one =
of a restricted list of values; in C it&#39;s basically a thinly-disguised =
integer, combined with a list of integer constants. In expl3 it could be in=
tegers or quarks (as in my bizarre idea above), whichever works better. (Or=
 neither, if the need for such a type is not there.)</p>

<p>Could you please explain what you meant?</p>
<p>=E2=80=94Joel</p>

--089e013d1dc6ebe7a904e10bbc6f--