User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
MIME-Version: 1.0
References: <00e701cf7542$114f8870$33ee9950$@post.harvard.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <537DA7E9.7080403@morningstar2.co.uk>
Date:         Thu, 22 May 2014 08:31:53 +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: Trouble with the .bool_set:N  property
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <00e701cf7542$114f8870$33ee9950$@post.harvard.edu>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 21/05/2014 23:14, pintar@POST.HARVARD.EDU wrote:
> Based on the discussion at http://tex.stackexchange.com/questions/179180
> there seems to be a problem with the definition of \__keys_bool_set:Nn.
> Namely, it is not obvious that the following code should fail
> 
>     \keys_define:nn { mymodule }
>       {
>         key-1            .choice: ,
>         key-1 / choice-a .bool_set:N = \l_mymodule_choice_a_bool,
>         key-1 / choice-b .bool_set:N = \l_mymodule_choice_b_bool
>       }
>     \keys_set:nn { mymodule } { key-1 = choice-a }
> 
> and yet it hangs because \__keys_bool_set:Nn actually creates a choice
> key with the choices 'true' and 'false' under the hood.
>
> I feel it would be more natural if the code above behaved in the same
> way as the following:
> 
>     \keys_define:nn { mymodule }
>       {
>         key-2 .bool_set:N = \l_mymodule_choice_a_bool
>       }
>     \keys_set:nn { mymodule } { key-2 }
> 
> In other words, the code that now hangs should just be setting the
> boolean to 'true'. If \__keys_bool_set:Nn and \__keys_bool_set_inverse:Nn
> were redefined along the lines of the code below, we'd get that result.

It's a bit more complicated than that :-)

If you look at the code, any case where someone sets up a 'choice of
choices' will fail. That's not good, and so before any worries about
booleans specifically I'll fix this more general issue. My feeling is
that trying to set up a 'choice of choices' key is an error in the
definition rather than at point of use, so I'm minded to trap such cases
and issue a error message. Does that sound reasonable? For example, what
is something like

  key-1                      .choice: ,
  key-1 / choice-a           .choice: ,
  key-1 / choice-a / value-1 .code = ...

actually going to achieve?

I have an approach in mind: probably will be checked in later today.

> Finally, and a lower priority: it might also be useful to add the
> properties .bool_set_true:N and .bool_set_false:N as well. For example,
> they could work like this:

One the specifics of boolean keys, I can see the point here about
set_true/set_false as they match 'normal' variable setting. On the other
hand, the original design here was to recognise that a boolean key is
somewhat 'special': it is a choice from a limited range of values.
Moreover, my thinking was that enforcing "true"/"false" as the values
avoided the possible need for people to allow for "on"/"off" or
"yes"/"no" (I've worried about this in the past). It was also meant to
indicate that a boolean key should be one that 'reads' as

    <thing> = (true|false)

rather than

    <thing> = (foo|bar)

as that seems less useful to the end user (if the options are more
complex than true/false then some other description is needed at the
documentation level anyway).
-- 
Joseph Wright