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