User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
References: <495160FA.8000004@morningstar2.co.uk>           
            <9EECA5EE-12A7-4C01-8311-7658BD3E8E04@gmail.com>           
            <op.umx28toejli536@macintosh.local>           
            <21363E65-E3FB-4495-A94E-6789AC0619A0@gmail.com>           
            <18778.35736.43421.950797@morse.mittelbach-online.de>
            <8A5C4EC7-9242-4A0E-9644-7BCE1BA029CC@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <495CB596.5090906@morningstar2.co.uk>
Date:         Thu, 1 Jan 2009 12:22:46 +0000
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Back to "token list" nomenclature; was Re: \tlist_if_eq:nn
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <8A5C4EC7-9242-4A0E-9644-7BCE1BA029CC@gmail.com>
Precedence: list
Status: R

Will Robertson wrote:
> Alternative: use tlp->tlist regardless and say that tlist functions that
> take inline arguments are generally more robust with # tokens than
> saving data to a tlist pointer. (Since I kind of like the =tlist= name.
> Wishy-washy, I know.)

I quite like this (I feel that "pointer" is not that easy a term to use
for existing (La)TeX programmers).  I'd go for:

- toks: The *only* place where "#" is supported in input outside (at
least when not catcode 12, per Will's other suggestion).
- tlist: A list of tokens, either stored (current tlp) or not (current
tlist).

I also note that the \edef behaviour of toks versus tlp/tlist is
important. By using only two categories, I'd say things are kept simple.
toks = can use # + odd \edef behaiour, tlist = no # + standard \edef
behaviour.

This leaves things like \tlist_to_str:n and \tlist_to_lowercase:n.  I'd
say that they still make sense in the toks/tlist formalism.

> Also, is there a way that the naming of the \token_ module can be
> incorporated into our naming scheme above? Or is that stretching things
> too far? (My current feeling is that it is.)

I'd agree: leave well alone!
-- 
Joseph Wright