Hi Lars > That is _one_ way to look at it, but probably not the only one; it > seems to me that: > * what started this discussion is that another model was plausible, > * the controversy is over cases where the two models disagree, > * what should be done is to (i) clarify the alternative model and > (ii) compare it to the original model, to see if the alternative > might actually be better. agreed. > Since it seems from the above that the original model was created as > nothing more than a naming scheme for shorthands, one should not be > surprised if some other model turns out to be more useful. well, the original model was not "just created" as a bunch of shorthand on the contrary I would say. The shortands are just a nice side effect. Furthermore, as you rightly observe there are traces in the documentation that still document various experiments with different models prior to chosing the one in use right now including the alternate one. 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) > I prefer not to have an opinion as to which model would be better, but > "T" and "F" seem quite useful, at least when reading code, so I > wouldn't want them abandoned. absolutely not ... me neither :-) It is true that you can't have shortcuts that indicate that the "true" code should be fully expanded first etc, but - T and F are receiving programming code (normally at least) and argument preprocessing on that makes little sense --- I haven't had any occasion that i remember where i did wish for it at least and I have programmed quite a lot in expl3 - if one really needs it then it it still possible to use the functionality without a shorthand, ie by putting an appropriate \exp_args:N... in front - T and F are really good eye catchers to see that conditional processing is happening and the fact that you always have (or can have) their variant forms, e.g. T alone F alone TF or FT (sometimes much easier to describe an algorithm this way) is another plus. So again they provide a functionality as well as serving a descriptive purpose. frank ps ok not really surprising that i defend the original model (though not all of its parts and extensions it saw over time) since I was one of the people coming up with it in the first place. So don't let this stop you from arguing for changes or even for radical model replacements ... a) I have changed my minds over aspects of this model many times (after using them) and b) I still believe that I'm open to reason (on a good day :-)