User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0)
            Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <CAFUtaNG+4N3rJR8Q09YFPYT3w46T5+uG_BLzdY2vThjiq2hQjQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <51CA0BAA.3070607@morningstar2.co.uk>
Date:         Tue, 25 Jun 2013 22:29:14 +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: Initialize l3keys definition from clist
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CAFUtaNG+4N3rJR8Q09YFPYT3w46T5+uG_BLzdY2vThjiq2hQjQ@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 20/06/2013 23:39, Joel C. Salomon wrote:
> On TeX.SE (http://tex.stackexchange.com/q/120258/2966), Prof. Enrico
> =E2=80=9Cegreg=E2=80=9D Gregorio helped me set up the below code, which=
 sets up an
> l3keys definition from a clist.
>=20
> Note that the property `.generate_choice:V` has to be created; is it
> perhaps a useful addition to l3keys?
>=20
> Note also the way I've set the default value to the first element of
> the clist. I would assume that the "idiomatic" way would be
>=20
>     font .initial:o =3D { \clist_item:Nn \c_jcsfonts_clist {1} },
>=20
> or something like that, but of course, the property `.initial:o`
> doesn't exist. And unlike the rest of Expl3, there is no clean way to
> generate variants of l3keys properties; egreg's code needed to call on
> `\__`-private functions. Might this, too, be a useful addition to the
> package?
>=20
> Code follows.
>=20
> =E2=80=94Joel Salomon
I see that this is the second simultaneous thread on l3keys: clearly a
useful part of expl3 :-)

I'm not quite sure how to handle the general 'variant generation'
question: unlike arbitrary functions, I'd imagine that the key
properties form a defined set. On the other hand, it certainly would be
possible to provide some form of interface to allow extensions: at the
moment, 'not sure'! I guess for the moment I can look at adding some
additional variants: the cost is low.

The question reminds me of a broader point: the business about
generating choices. My original preference was that properties should
take a single "n"-type argument

  key-name .property:n =3D value

as this uses 'all' of the value. That led to the
.choice_code:n/.generate_choices:n stuff. Later, I was not so sure that
was the best plan (not all that clear), hence bringing in .choices:nn to
do both parts in one.  (I see the other key-related thread also asks for
'two-part' key properties, so this looks not-unpopular as an interface.)
I'd like to know what other people think of the two approaches.
--
Joseph Wright