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.