9 dec 2007 kl. 20.14 skrev Morten Høgholm:

>

> My problem with calling it \int_set:Nx is that this implies there is a 

> base form \int_set:Nn but for these functions working with the 

> built-in registers of TeX, it doesn't make much sense to have 

> different specifiers as full scan_(int|dimen|glue) expansion always 

> takes place. 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?



Also consider that an important distinction between material being 

expanded and material not being expanded lies in what commands may be 

used therein.



>> Should the arg-spec indicate whether a function is expandable or

>> not?

>

> Ideally, no, it shouldn't. It should be clear from the documentation 

> what is expandable and what is not.



Is that a state that the LaTeX3 sources is currently supposed to be in, 

or not? One thing that *irritated* me when reading a bit of it last 

week was that it frequently wasn't clear whether something was 

expandable or not, and for many things that is something that I'd need 

to know.



> Something like what Heiko does in zref?

>

> Usually the x expansion meant "uses \edef" and so they were all 

> non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have 

> functions doing full expansion like \numexpr and friends



No need to go that far for examples. \csname ... \endcsname should be 

obvious to all, and you can play quite a lot of tricks with \number as 

well. Another important expandable primitive doing full expansion (as 

far as it needs to) is \if, which is used in docstrip to implement 

evaluation of guard expressions (in particular there was really no need 

for the eTeX \unless primitive, since \if could already be used to 

negate conditions).



Lars Hellström