Frank Mittelbach wrote: > Let us step back and reevaluate what the arg forms are supposed to mean: > > \foo:abc % abc are placeholders for real arg specifiers > > is intended to be a short form for saying > > - do "a" with the first argument do "b" with the second and do "c" with the > third argument prior to passing the argument values to the base function > \foo:nnn > > - it is really only a short form of \exp_args:Nabc \foo:nnn > > It makes no statements about what \foo:nnn does with the arguments it > receives. I see. I got the meaning of arg specs wrong. But now it makes sense. > but lets recap once more > > the current model is a functional model in the sense that it provides the > programmer with additional functionality which is > > - a way to manipulate arguments passed to a macro prior to calling the macro > This model is available a) as building blocks to be used with any kind of > macro, e.g., \exp_args:N... and as b) shorthands to even further reduce > complexity in the code by turning providing memorable shorthands often used > forms of \exp_args:N... \foo:nnn as \foo:... > > in contrast the other model outlined in the discussion (which we experimented > with as well) is a descriptive model with essentially tries to describe what > kind of arguments a certain function accepts (and in case of your description > below additionally tries to describe what the function does with its > arguments) > > - a descriptive model helps to understand better what a function does > > - however, there are much too much ways of dealing with arguments inside a > function so that codifyin them will be a) incomplete and b) resulting in > a lot of complexity with little gain > > - it doesn't provide any additional functionality to the programmer other > than training his/her brain-cell on whether the third arg of some function > \foo:... was called "r" or "n" or ... > > - there is also the problem that many higherlevel commands simply do not fit > into a model that claims that each argument is typed, many commands do > accept several types and internal check what they receive and act > accordingly. Problem then is what would those get in terms of descriptive > labels? > > > so in the end we ended up with > > - going for the arg preprocessing functionality > > - providing a few bits of descriptive guidance in addition for the most > important parts where we thought they would be useful/helpful, e.g., using > upper case N to indicate that a function expects a single token rather than > a braced argument or to use T and F to indicate branches of a > conditional. This is what I meant when using the word "inconsistency" but > that usage was probably misguided as I wasn't suggesting that TF should > vanish (however, O for example, turned out to be fairly useless) Thanks for these explanations. This whole discussion showed me that things are much more intricate than I thought. I will keep this in mind when writing code. I need some more experience before I can comment on the pros and cons. Ciao Andreas ps: I couldn't respond ealier since I was windsurfing in the Red Sea for the last two week. It was marvellous.