User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
References: <LISTSERV%200811192230181624.04A3@LISTSERV.UNI-HEIDELBERG.DE>      
            <27990a880811191758x2a29ecb4m33d2dcead1f32093@mail.gmail.com>      
            <859ec5630811200508x17ef357dvc7cf352f5bc1031f@mail.gmail.com>      
            <FFBA056D-6B16-4FB2-AD0F-CD95B6719230@gmail.com>           
            <492E623B.1090300@morningstar2.co.uk>           
            <492F05D6.3060103@morningstar2.co.uk>
            <1F3BAD8F-E4CF-4110-8D8E-50B31B47FB22@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <492FA9B7.5040802@morningstar2.co.uk>
Date:         Fri, 28 Nov 2008 08:20:07 +0000
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: \exp_after:NN
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <1F3BAD8F-E4CF-4110-8D8E-50B31B47FB22@gmail.com>
Precedence: list
Status: R

Hello Will,

> Thanks for the comprehensive list!
> Your suggestions are good in that they don't involve *too* much change
> from what we're used to. 

That was largely because I'm broadly happy with the situation "as is".
I was thinking about the small-ish number of awkward cases, and trying
to make them clearer.

> In the following table, "W" is a tentative suggestion following from some
> comments by Frank last year; "J" is Joseph's suggestion, and "C" is what
> we've got now.

I did my best to stick with the current thinking (letters are based on
an explanation of what they do).  You could perhaps include "z" in my
list as a complement to "W", with z representing other expansion
possibilities and W being more strictly for delimited arguments.  In
that way, a z argument with always represent one thing, whereas W can
mean any arbitrary list of stuff.

>      t    T    Braced tokens    Braced         True branch
>      f    F    Braced tokens    Braced         False branch
> 
> What would happen if we dropped the true/false flags from the arg spec into
> the function names? E.g.,
>   \tlist_if_in_TF:nn { <tlist> }{ <str> } { <true> }{ <false> }

Speaking from my own experience, I quite like the :T, :F, :TF idea.  The
problem with the above is that \tlist_if_in_TF:nn needs four arguments,
so it should really be \tlist_if_in_TF:nnnn.  I think it is then much
harder to see what is going on.  So if it were down to me I'd keep the
T/F idea, although I'd aim for lower case as these can take braced
arguments. (Speaking of which, I might revise my suggestion again, to
stick with :w in lower case for the same reason: braces are possible for
:w arguments.)

> (Although I suppose there's no reason we couldn't currently write
>   \bool_double_if:NN_TT_TF_FT_FF )

Why not just \bool_if:NN_TT_TF_FT_FF?  A slight abuse of the system, but
this is one of those edge cases where flexibility is needed.

> While we might be able to create a better system than we've got now, is
> it worth it?

Once again, if it were down to me I'd not make more changes than are
really needed.  In that sense, this entire discussion could be somewhat
redundant: things already work reasonably well.  I'd still argue that
\exp_after:NN is not representative of what it does, so using the
current specifiers would prefer \exp_args:NE.  That change at least
should be relatively easy.

If other changes are made, I'd suggest that there will be something of a
"knock on" effect, and so it is only worth doing if the entire result is
more logical (e.g. just changing f => s is not worth it).  Of course, I
think my suggestion is not bad :-)
-- 
Joseph Wright