Will Robertson wrote:
> In everything below, I'm especially trying to ignore the syntax of the
> template definitions entirely; I think the two points I raise below are
> fairly independent to whether we use letters or tokens or whatever to
> define the template keytypes.

Seems reasonable provided we always end up with the same functionality
(which is the plan).

> That is, we should offer something that looks like template's
> 
>        above-skip         =L           [0pt] \l_caption_above_skip        ,
>        number-format      =f2      [#1~#2:~] \caption_number_format:nn    ,
> 
> as well as providing a function such as
> 
>   \DeclareTemplateDefaults{type}{template}{
>     above-skip = 0pt          ,
>     number-format = {#1~#2:~} ,
>   }
> 
> Template authors may then use one or the other as appropriate for the
> application, and users of layer 1 can use the function to help create
> their instances.
> 
> PROPOSAL: Whatever the interface itself, both ways of setting defaults
> should be offered. (And whether it's optional or not, per Joseph's
> recent post, is still up for debate.)

This seems reasonable to me: I'll be interested to see how we end up
coding it :-)

>        above-skip    .skip_set:Nn    = \l_caption_above_skip     {0pt}    ,
>        number-format .func_2_args:Nn = \caption_number_format:nn {#1~#2:~},
> 
> I would prefer to write
> 
>        above-skip    .set:Nn = \l_caption_above_skip     {0pt}    ,
>        number-format .set:Nn = \caption_number_format:nn {#1~#2:~},

A bit more challenging than my current implementation!  However, quite
doable I think.

> On this point, Frank wrote:
>> - the key settings more or less completely hide the nature of the key, eg
>>   .functions:N means a function is expected (in contrast to a variable of
>>   some kind) but it is not clear what kind of function is needed or
>> what kind
>>   of variable is expected
> 
> I don't understand this, sorry. If I write '=f2' then I don't know what
> kind of function is needed (unless you mean the number of arguments?
> Which follows from the function name...), and if I write '.set:Nn
> \l_caption_above_skip' then it's clear that we're setting a length
> register...so in both cases I don't follow your criticism. (But I'm
> probably misunderstanding your point.)

I suspect Frank means that with something like

  number-format      =f2      [#1~#2:~] \caption_number_format:nn

you can look down the columns to see the "type" of key being defined
without needing to understand the definition itself. So here you can see
that a function with two arguments is being set up without needing to
know that :nn also indicates this.

>   Aside: The other reason I like implicit .set:Nn is for
>     "extra variable/data types". If Joseph were to invent an
>     expnum datatype that allowed input like '3e-4' for siunitx
>     then (and we allowed this sort of thing) template
>     definitions would be able to use the corresponding
>     \expnum_set:Nn function without adding any extra code
>     (or letters to remember) to template itself.
>     (For this to work, each datatype would have to declare
>     itself in a property list with a name and functions for
>     using it. Not sure if it's just a crazy idea or something
>     useful, at this stage of the day.)

Aside: At some point I need to sort out floating-point numbers, and
there I may well want a _fp variable type. So the idea is more than
theoretical.

> OPTIONS:
> 1. Only explicit keytypes (no automagic) like template is now
> 2. Only implicit keytypes like template-alt is now
> 3. Both of the above
> 
> I'd like to propose option #3 not because I like "automagic" but because
> I believe it will help to simplify the interface, while still providing
> "plain" keytypes for those cases where the disambiguation is necessary.

I'm happy with this also. (As with \cs_set:Nn, the simplification does
seem worth it to me.)

> These are only two points, but I hope we can decide on them before
> moving onto the next troublesome parts. As I said, I'm trying to ignore
> the interface at this stage so I don't care if the default is optional
> or not or before the variable or after it; similarly, all I care about
> with the different keytypes is that we need a bunch of them for
> different variables and other things, not what they're called or what
> they look like.
> 
> So the big question is: can we agree on the two points raised above,
> first? :)

Well I'm happy.
-- 
Joseph Wright