LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Date: Wed, 12 Dec 2007 11:17:56 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Lars Hellström <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Transfer-Encoding: 8bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (82 lines)
10 dec 2007 kl. 17.02 skrev Frank Mittelbach:

> Morten H°gholm writes:
>>
>> Technically there wouldn't be any difference of course. Only the
>> implication that everywhere else, x means there is also an n base
>> function, which is also more or less why I chose the n form initially.
>
> and with good reason I think.
>
> 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.

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.
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.

One principle that could be taken as foundation for what we've seen of 
an alternative model is that the argument specifiers are about what is 
_allowed_ in an argument rather than what will happen to that argument. 
With this interpretation, an "n" specifier means "any <general text>", 
whereas an "x" specifier means "<general text> without fragile 
commands; will be fully expanded", and a "c" specifier means "<general 
text> that expands to a sequence of character tokens; will be 
\csname'd".[*] There are actually traces of this in the source, in the 
form of the unused (but documented) specifiers "i", "d", "g", "m", "b", 
and "r" which would then mean "<general text> that expands to an 
<integer>/<dimen>/<glue>/<muglue>/<box-spec>/<rule-spec>; will be 
interpreted as such".

[*] Technically, the description of the c specifier in the source is 
too restrictive; the character tokens don't have to be category 11 or 
12.

This model probably calls for additional specifiers; e.g. booleans are 
certainly common enough in the source to warrant a specifier of their 
own.

> Some people have suggested we shouldn't provide the short forms, 
> though I feel
> that they make life much easier once you get the hang of it, but in any
> case they are only shorts for "manipulate some arguments prior to 
> passing them
> to a function"
>
> There is a bit of inconsistency here in that something like T F are arg
> specifiers that give information about the argument purpose rather 
> than about
> a manipulation of the argument and perhaps some of the concepts should 
> be
> reviewed and unified -- but the direction should be less arg 
> specifiers not
> more

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.

Lars Hellstr÷m

ATOM RSS1 RSS2