Hello,



Bit of a slow (but hasty) reply :)



On 28/11/2008, at 6:50 PM, Joseph Wright wrote:

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



That's true, and not as concise.



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



On the other hand, as exceptions, 'F' and 'T' stand out a little bit  

more than if they were lowercase :)



But yes, in general I think it's better to keep them on the "right" of  

the ':'.



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



Good idea, I think.



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



Yes, I agree!



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



Well, I think writing it as \exp_after:wN is "most correct", but in  

the end I hope that we shouldn't really be using it much in expl3  

programming.



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



Indeed; we should be very sure the new system is actually "better" and  

we're not just changing things for the sake of it.



> Of course, I

> think my suggestion is not bad :-)



I think both your suggestions and Morten's are quite useable for our  

needs; I don't have much opinion between the two. As Frank always says  

"language design isn't easy" :)



W