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
Show All Mail Headers

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

Print Reply
Subject:
From:
Ulrike Fischer <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 30 Aug 2011 10:24:55 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
Am Mon, 29 Aug 2011 21:27:46 +0100 schrieb Joseph Wright:


>> 4. The introduction makes a difference between "functions" and
>> "variables" but doesn't say which package(s) deal with the one and
>> which with the other type. It would also help if there were a rule
>> of thump when a command without argument should be better defined as
>> a function and when as variable. 
> 
> I'm not quite clear what you mean here. 

As in the meantime I understand things better it is a bit difficult
to say exactly why I was confused at the start. But I think it would
be better if the chapter names of packages handling variables/data
types would contain the word "variable". E.g. 
"XI The l3tl package Token lists variables "



>> 5. In the clist package I was quite bewildered because they didn't
>> seem to be a command to actually *fill* a list. At the end I found
>> that I can add more than one item with 
>> \clist_put_left:Nn.
> 
> I assume you were looking for
> 
>   \clist_set:Nn \l_my_clist { ... }
> 
> and did something like
> 
>   \clist_put_right:Nn \l_my_clist { a , b }

Yes.


> This rather misses the point of a structured data type: you are supposed
> to deal with each item separately (with a loss of performance, regrettably).
> 
>   \clist_put_right:Nn \l_my_clist { a }
>   \clist_put_right:Nn \l_my_clist { b }
> 
> Now, comma lists are a bit odd as they are really an input form which is
> somewhat supported as a stored data type. There has been some discussion
> within the team about this, as in general the seq data type is more
> robust. We certainly need to be handle 'explicit' comma lists
> 
>   \foo:n { a , b , c }
> 
> but the situation with 'stored' ones is less clear. (I'm still not sure
> about the entire stored-comma lists business. I wonder if we should
> insist on conversion to sequences.)

Looking at sequences I think I could use them too (I need to
generate a lot of similar commands for the list
(king,queen,rook,bishop,knight,pawn)). But whatever is used to store
ordered lists of items: There should be somewhere mentioned how you
are meant to put at the start a lot of items in such a list
("initialize with values").  



-- 
Ulrike Fischer 

ATOM RSS1 RSS2