LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 30 Aug 2011 10:24:55 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Ulrike Fischer <[log in to unmask]>
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 }


> 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