References: <00e701cf7542$114f8870$33ee9950$@post.harvard.edu> 
            <537DA7E9.7080403@morningstar2.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AQIxL1g7aqegxfBTqmzE8f5eX9UbvQHhPKs1mnnHfCA=
Content-Language: en-us
Message-ID:  <010801cf759c$84533fb0$8cf9bf10$@post.harvard.edu>
Date:         Thu, 22 May 2014 05:02:10 -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: pintar@POST.HARVARD.EDU
Subject: Re: Trouble with the .bool_set:N  property
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <537DA7E9.7080403@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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

It usually is!

> 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?

Yes, I'd noticed that it will fail (I actually mentioned it in passing in
the 
tex.stackexchange discussion), but it didn't worry me so much precisely
because
I couldn't think of any reason why one would want to set up a case like
that.
Of course, it's definitely better if attempts to do so raised an error
instead
of getting stuck in a loop!

> 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).

I see your point, but I can also imagine cases where at the user end it
might
feel more natural to have something like

    \mymoduledoclevelsetup{ turnfooingon }
    \mymodulecoclevelsetup{ turnfooingoff }

instead of

    \mymoduledoclevelsetup{ fooing = true }
    \mymoduledoclevelsetup{ fooing = false }

I guess the decision here is really between nudging package authors towards
uniformity and trusting them to develop a syntax that's best for their
target 
users on their own (it's not exactly imposing uniformity, because a package 
writer stubborn enough could always type the few extra characters to get
" turnfooingon .code:n = { \bool_set_true:N \l_mymodule_fooing_bool } ").

I tend to be a fan of uniformity myself, but I wouldn't go as far as to
claim
I have a worked out ideological position on it. :)

Best,

Jura