Will Robertson wrote: > Hi, > > On 13/08/2009, at 2:43 PM, Joseph Wright wrote: > >> Are we approaching a consensus on this (if not what everyone considers >> ideal, at least on something most of us can live with)? > > Seems great to me. I think it strikes a good balance. > I'll be interested in hearing Morten's and Frank's views (although I > understand they might not get the opportunity). We haven't really deviated far from the xparse model as written by Frank et al., so I'd hope he at least will be reasonably happy. It is more a question of refinement and getting at least some parts finalised (to be agreed once there is an implementation based on this discussion: perhaps next week). > As far as the definition of the processors is concerned, I think I > prefer using a pre-determined toks variable rather than a more abstract > "#1". That is, to write > > { >{\my_sanitise:n} m } > \cs_set:Nn \my_sanitise:n { > \toks_set:Nn \l_xparse_arg_toks { <something with #1> } > } > > rather than > > { >{\my_sanitise:Nn} m } > \cs_set:Nn \my_sanitise:Nn { > \toks_set:Nn #1 { <something with #2> } > } > > It looks better, to me, that processor functions have a single-letter > signature in their simplest form. (It seems pretty clear that we should > be using functions with expl3 names here?) I'm fine with that. On the naming of functions, xparse provides stuff at design level, such as \IfNoValueTF. So we might consider a small set of design-level functions, with the assumption that any extras would be in internal namespace. I'm thinking of a wrapper for \detokenize, and perhaps a de-babel one (to remove active punctuation at the outer level). > Also, I think this is about as simple as we can get. We could > theoretically have a function like > \xparse_return_arg:n { <something with #1> } > instead of the \toks_set:Nn, but this would still require scratch > variables to manipulate #1 in the first place. So no gain. Yes, we don't really gain much. -- Joseph Wright