LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Will Robertson <[log in to unmask]>
Sun, 7 Feb 2010 18:56:12 +1030
text/plain (50 lines)
On 07/02/2010, at 7:36 AM, Joseph Wright wrote:

>> - What is the conceptual difference between token lists and token
>>   registers?  In what cases should I use which one?  
> 
> At the implementation level, a token list is a macro, whereas a token
> register is, well, a token register. Most of the time, token lists are
> more convenient as they don't need an access function. There are a
> really limited number of places where a token register is needed:
>  - When the stored material might contain # tokens
>  - When you want to have exactly one expansion inside an x scenario
> That is of course the same as any other TeX programming, but we should
> I guess discuss this somewhere.

l3toks contains a short discussion of this at the beginning:

% There are fewer restrictions on the contents of a token register over
% a token list variable. So while \meta{token list} is used to describe
% the contents of both of these, bear in mind that slightly different lists
% of tokens are allowed in each case. The best (only?) example is that a 
% \meta{toks} can contain the "#" character (i.e., characters of catcode 6),
% whereas a \meta{tl var.}~will require its input to be sanitised before that is
% possible.
%
% If you're not sure which to use between a \meta{tl var.}~or a \meta{toks}, 
% consider what data you're trying to hold. If you're dealing with function
% parameters involving "#", or building some sort of data structure
% then you probably want a \meta{toks} (e.g., \file{l3prop} uses \meta{toks}
% to store its property lists).
% 
% If you're storing ad-hoc data for later use (possibly from direct user 
% input) then usually a \meta{tl var.}~will be what you want.

Improvements welcome.

>> - Why is there no separate stack/queue data type?
> 
> That is what sequence stacks are for: expl3.pdf, p. 12:
> 
> "l3seq This implements data-types such as queues and stacks"
> 
> This is where I have used the seq data type rather than using comma
> lists: when wanting to set up a stack.

Right; comma-lists for user-based input (or where the commas just make sense) and seqs for more robust storage of arbitrary material.

Morten has implemented a more generic data type for expl3 in which (if I recall correctly) items can be referenced with indices as well as with using push/pop operations, but they have yet to make a public appearance.

-- Will

ATOM RSS1 RSS2