LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 10 Dec 2007 17:02:10 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=iso-8859-1
From:
Frank Mittelbach <[log in to unmask]>
Parts/Attachments:
text/plain (49 lines)
Morten Høgholm writes:
 > On Sun, 09 Dec 2007 22:33:12 +0100, Lars Hellström wrote:
 > 
 > Hi Lars,
 > 
 > > 9 dec 2007 kl. 20.14 skrev Morten Høgholm:
 > >>
 > >> So perhaps an alternative could be to use something like
 > >>   \int_set:Nr <int> {expression}% r for register?
 > >>
 > >> Opinions?
 > >
 > > How would such an r be different from x?
 > 
 > 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. 

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


frank

ATOM RSS1 RSS2