LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Type:
text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Date:
Sun, 9 Dec 2007 20:14:31 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Morten Høgholm <[log in to unmask]>
Content-Transfer-Encoding:
8bit
In-Reply-To:
MIME-Version:
1.0
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (55 lines)
On Wed, 05 Dec 2007 22:57:44 +0100, Andreas Matthias wrote:

> Morten Høgholm wrote:
>
>> On Sun, 02 Dec 2007 14:35:33 +0100, Andreas Matthias wrote:
>>
>> True, the base form of the function \int_set: does do this x
>> expansion.  However, these assignment functions are a bit different
>> from other types  because there is no difference between
>> \int_set:Nn and \int_set:Nx and so  perhaps it is better to stick
>> to the base form definition using Nn rather  than Nx as that would
>> imply there is a base form too.
>
> When I first used these functions I added a lot of \exp_args:... and
> \exp_after:NN just to realize afterwards that they are not necessary
> at all. An x arg-spec would have helped me a lot to get things right
> from the beginning.

Noted. I see your point. Thanks for the feedback: it is good to know what  
we can do better in the documentation.

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?

> 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. 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 and \pdfstrcmp  
(does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me:  
the notes from the Oldenburg meeting mentions an \expanded primitive:
   \expanded <general text>
   Expandable command returning the full expansion
   of the tokens in <general text>.
So since this pretty much exists inside \pdfstrcmp as it is now, it could  
go into pdfTeX 1.50 and we would be free of these problems. Except of  
course, \expanded is already used a lot in ConTeXt with different  
semantics.

Any opinions from the ConTeXt/pdfTeX people here?

Cheers,
-- 
Morten

ATOM RSS1 RSS2