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