On Wed, Jul 17, 2013 at 2:45 AM, Bruno Le Floch <[log in to unmask]> wrote: > A: Argument specifiers and variants > =========================== > > Well, there are very many conditionals in expl3, and experience has > shown that the specifiers T and F are useful for visibility (they > would be even if we only provided the TF versions of conditionals and > not both T and F too). Oh, I love T and F. Slightly off-topic question: why are there no FT variants? I've encountered situations where it would have made the control flow a lot more readable. This is certainly not critical but also, I expect, quite painless to add. > What about D? Well, it would be more natural to label all of those > functions as :w and be done with it I don't see why it should be an argument specifier at all, since it says nothing about the arguments. Just use a notation outside the public interface conventions, like `\name::`. > A new variant type :Z > had better (1) alter "expl3 user"-accessible parts of TeX's memory as > little as possible, hence behave mostly as a pipe that takes some > tokens as an input and returns other tokens, (2) either be such that > most N-type arguments (all?) or most n-type arguments can be turned > into Z-type, (3) so far at least we only have variants which perform > some kind of expansion. Such requirements are fine so long as they serve a purpose other than "well, that's just how we do it". I agree that the 'purity' or 'side-effect freedom' of these variant types is a noble goal to strive for, but if more and more (legitimate) exceptions are made (such as :x and the fp-stuff), it becomes somewhat meaningless to hold on to this restriction and you'd be better off properly documenting and regulating side-effecting variants. Don't get me wrong though. I agree now that :u and :U should not be argument specifiers. I still think :r might make a nice one, but I do understand that you wouldn't add such a feature without evidence that people (other than just me) would find it useful. > If there was no alternative to providing an argument specifier :r, > then I might have been in favor of adding it. However, any > non-expandable specifier which is a variant of :n can be very well > approximated using a function that sets a temporary token list, then > using :o (or :V) expansion. Namely, if :Z (here, :r) is a variant of > :n, > > \foo:NnZx \a { AB } <Z-arg> { ghi } > % is equivalent to > \tl_set:NZ \l_same_for_all_expansions_tl <Z-arg> > \foo:Nnox \a { AB } \l_same_for_all_expansions_tl { ghi } But this is the case for :x too. > B: Baby-steps towards objects > ======================= I don't have time to process this section right now. But I will, because I'm very interested. >> \with:Vn \l_variable_tl { >> \bla:n { \do_not_expand_me bla bla bla #1 bla bla } >> } > > This situation does not need unique identifiers. Simply Oh, indeed. This was just a "hello world"-level example of `\with`. >> Here's how I currently implement my `\something_map_inline`s. I use >> the non-expl3 version of `\with`, because expl3 doesn't have :U. >> >> \cs_new_protected:Nn \something_map_inline:Nn { >> \with {Unn} [map_inline] [#2] { >> \cs_set:cpn {##1} ####1####2 {##2} >> \something_map_function:NN #1 {##1} >> } >> } > > I'm not fond of the fact that ##1 and ##2 in the body of \with are not > at all on the same footing, since ##1 is the unique name and ##2 is > the original #2. I don't understand. When are different parameters ever on the same footing? `\with` simply allows you to pass any 8 (expl3) or 7 (non-expl3) values, expanded however you like, into a block of code with one command. > Also, passing arbitrary parameters (here #2) > surrounded only be square brackets is very fragile, as it tends to > break if #2 contains some ]. Ah, easy enough to fix. ;-) \cs_new_protected:Nn \something_map_inline:Nn { \with {Un} [map_inline] [{#2}] { \cs_set:cpn {##1} ####1####2 ##2 \something_map_function:NN #1 {##1} } } > I see that, but I think the ptr package should actually be responsible > for building its own unique names. Well, if another package already encapsulates unique-name-creation, why reinvent the wheel? Best, -- www.mhelvens.net