9

I tend to get \IfBooleanTF and \IfNoValueTF (and the other similar macros) mixed up and wondering which is the correct ones to use for the following optional parameters: s, o, d, g, k_ (and k^) and t_ (and t^). From the documenation it seems that one should use:

  • \IfBooleanTF: s, t
  • \IfNoValueTF: o, d, g, k

Questions:

  1. Is the above list of macros to use correct?
  2. What is the intention of distinguishing between \IfBooleanTF and \IfNoValueTF? Wouldn't it make sense to just have one macro that does both jobs? Or, is there a case where a distinction is required? t and k using different macros is especially confusing to me.

My reason for asking is: If I can understand the logic behind this, perhaps I'll be able to remember to use the correct ones.

Follow-up Question:

References:

  • With s or t you ask TeX to see whether or not a particular token follows, so it's a true or false situation; the token is never used as such. – egreg Dec 23 '16 at 9:11
  • You should add also d to the argument types that need \IfNoValue(TF) – egreg Dec 23 '16 at 11:50
5

Yes, the above is correct.

The two cases are logically distinct as you are passing different information. The aim of xparse is to make this structural information clear.

For \IfBoolean(TF), the argument is a single token which can only be one of two values: TRUE and FALSE. A value is always returned by the t (and s) argument types, and the test is there to see which it is. One may also reverse the logic returned here using \ReverseBoolean: the presence of the token does not have to map to logically TRUE.

\DeclareDocumentCommand \foo { >{ \ReverseBoolean } s }
   {
      \IfBooleanTF #1
        { Star not present }
        { Star present }
   }

On the other hand, argument types which grab 'some tokens' may not be present (so yield \NoValue), be present-but-empty or be present-and-non-empty. The logic that something is present cannot be reversed so \IfNoValue will always be true only if the optional argument was not given at all.


The k-type argument has recently been adjusted: you now want e-type. This one is somewhat specialised and the team have had quite a bit of discussion about the correct form here.

  • 1
    Could you sum up what has been the discussion around k (now e). I'm out of the loop, but I'm interested. No details, just in the broad sense. – Manuel Dec 23 '16 at 9:42
  • I noticed that the k parameter is not mentioned in the 2016-11-21 version of the xparse documentation. Can I safely assume that its functionality will be left intact or will it evenatually be removed? Also, can you add to your answer at Xparse t argument type (underscore with optional parameter) to include an example of the e type option (not sure I fully understand it from the documentation). – Peter Grill Dec 23 '16 at 9:51
  • @Manuel That would be a separate question I think – Joseph Wright Dec 23 '16 at 10:10
  • @PeterGrill As covered in the documentation, e-type is experimental: we have to have some way to test out ideas without committing to everything up-front. We are likely to retain some form of '^/_-like' input parsing, but the detail is more tricky. (Discussion of these ideas is the is best on LaTeX-L) – Joseph Wright Dec 23 '16 at 10:16
  • @JosephWright: Ok, but what is the plan for the k parameter. Is the plan to leave it as is, or should switch to using the t paramameter in my code? – Peter Grill Dec 23 '16 at 10:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.