Sender: |
|
Date: |
Wed, 5 Aug 2009 06:12:43 +0100 |
Reply-To: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
7bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=ISO-8859-1 |
From: |
|
Parts/Attachments: |
|
|
Will Robertson wrote:
> As far as I'm concerned, it's now or never for the expl3 code (some
> might even say it's too late). I think we're at a stage where we can
> state: we've iterated some ideas and this seems the best we can achieve;
> if you use it now we will support backwards compatibility to the best of
> our ability.
Agree entirely. I'd imagine we may find that one or two functions have
to be re-worked at some point, but as a percentage of the whole this
should be very small. I'm not sure stability in the LaTeX2e sense
(nothing changes) is desirable in any case: sometimes you need to "bite
the bullet".
> P.S. Joseph, I can't help noticing your use of \cs_new_nopar:Nn. I know
> that without an argument this usage is (in TeX terms) more "correct".
> But, unless I was drastically mistaken, the assumption we made when
> naming these functions was that it didn't really matter to have some
> spurious \long's and we really wanted people to use \cs_new:Nn in all
> cases except when they *specifically* wanted to restrict \par. (Since
> the \long case is more general and more frequent. Restricting \par in
> the input is better achieved when defining the user commands than the
> underlying commands beneath them.) Unfortunately, there are lots of
> cases in source3 where this convention is not followed, but only because
> the translation was performed mechanically. What do you think about the
> whole thing?
My take (in what I've done in siunitx) is as follows. Where there is any
chance that \par might pop up (most functions), I've used \cs_new:Nn.
I've only used \cs_new_nopar:Nn in two types of case:
- Functions with no arguments. As there are no arguments, the question
of \par tokens never arises. So it makes no difference whether I use
\cs_new:Nn or \cs_new_nopar:Nn. As I've said before, I feel it is better
to use more restricted functions if possible.
- Cases where I'm coding an aux function with known input. In the
example I gave:
\cs_new_nopar:Nn \siunitx_load_check: {
\clist_map_function:nN { SIunits, sistyle, siunits, SIstyle }
\siunitx_load_check_aux:n
}
\cs_new_nopar:Nn \siunitx_load_check_aux:n {
\group_begin:
\@ifpackageloaded {#1} {
\msg_error:nnx { siunitx } { incompatible-package } {#1}
} {}
\group_end:
}
\siunitx_load_check_aux:n is only ever used to process an item from the
in-line clist in \siunitx_load_check:. They can never contain \par, so
again I can use the "most restricted" function. So there should be no
cases where user input is restricted by my choices: I'm using xparse to
do that. (Having said that, I should probably check through the code
I've to make sure I've stuck to that scheme carefully.)
--
Joseph Wright
|
|
|