References: <87k5nxw76i.fsf@buckbeak.hogwarts>
            <op.t2uslqp4ss64je@macintosh.local>
            <87tzmwkdnr.fsf@buckbeak.hogwarts>
            <op.t2202imrss64je@macintosh.local>
            <f0c56dd5cf649ae9848723a7a9095df7@residenset.net>
            <op.t237fhmxjli536@gdhcp88.gbar.dtu.dk>
            <18269.25346.697845.365250@morse.mittelbach-online.de>
            <281f1dab73f627993b7d112bbabf8b74@residenset.net>
            <18271.50750.510995.826662@morse.mittelbach-online.de>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <874pe9yvk7.fsf@buckbeak.hogwarts>
Date:         Sun, 23 Dec 2007 22:01:44 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Andreas Matthias <amat@KABSI.AT>
Subject: Re: Misleading cs names?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <18271.50750.510995.826662@morse.mittelbach-online.de> (Frank
              Mittelbach's message of "Wed\, 12 Dec 2007 12\:30\:06 +0100")
Precedence: list
Status: R

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.