Lines: 63
References: <bs7n95ikt65p$.dlg@nililand.de> <4E5B6BF7.80208@morningstar2.co.uk>
            <CANQYN6w2ZrLzPY4UqJSwFU_A+Vfw=ApeYgPWjg1UVYTv-k-rew@mail.gmail.com> <eab99gnhctiy$.dlg@nililand.de>
            <4E5BA7FC.8060705@latex-project.org>
            <w20e629w9r1q$.dlg@nililand.de> <4E5BF642.20901@morningstar2.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: 40tude_Dialog/2.0.15.41de
Message-ID:  <yxy755p0xoog.dlg@nililand.de>
Date:         Tue, 30 Aug 2011 10:24:55 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Ulrike Fischer <news3@NILILAND.DE>
Subject: Re: missing or unclear concept documentation
To: LATEX-L@listserv.uni-heidelberg.de
Precedence: list
Status: R

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