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.