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
Content-Type:
text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Date:
Mon, 10 Dec 2007 11:29: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 (82 lines)
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.

We have umpteen different expansion designations (leading my thoughts to a  
Commodores song which is a sign of me not getting enough sleep and/or  
coffee) and I know adding an extra is not helping that situation either. I  
am happy to get comments from expert users such as you and Matthias so we  
can make it work the way you'd expect.

>> 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.

As you say, it is irritating not to know whether or not a function is  
expandable and it is something I would very much like to change. Soon. I  
suggested:

>> Something like what Heiko does in zref?

How would you like it to appear?

It'd be fine by me if the sources were changed to something such as

% \begin{function}{
%		   \csexp{clist_map_function:NN}
%                  \csexp{clist_map_function:cN}
%                  \csexp{clist_map_function:nN}
% }

% \begin{function}{
%		   \cs{clist_map_inline:Nn}
%                  \cs{clist_map_inline:cn}
%                  \cs{clist_map_inline:nn}
% }

or similar.

[...]
> 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.

Currently we are well on our way to MI ways of using \romannumeral and  
some are due to the lack of \expanded. Others are just very useful for  
space trimming.

> 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

yes, \if is good for tricks as well.

> (in particular there was really no need for the eTeX \unless primitive,  
> since \if could already be used to negate conditions).

I never quite saw the big advantage either, especially because you can't  
just do
   \def\whatever#1#2{\ifx#1#2equal\else not\fi}
   \unless\whatever

Cheers,
-- 
Morten

ATOM RSS1 RSS2