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 :-)