Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
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>
Message-ID:  <8A5C4EC7-9242-4A0E-9644-7BCE1BA029CC@gmail.com>
Date:         Wed, 31 Dec 2008 11:44:52 +1030
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: Back to "token list" nomenclature; was Re: \tlist_if_eq:nn
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <18778.35736.43421.950797@morse.mittelbach-online.de>
Precedence: list
Status: R

On 31/12/2008, at 7:29 AM, Frank Mittelbach wrote:

> So I personally would go KISS and offer
> functions that limit the accepted input to balanced token lists  
> without #.

Another random thought: since users "shouldn't" be defining new macros  
within the body of their documents, I think LaTeX3 should have  
something like the equivalent of
   \AtBeginDocument{\catcode`\#=12}

Of course, there could be markup to allow them to write more  
definitions mid-document if they really want/need.

* * *

But that's rather separate from what we've been talking about :)

It seems to me that the two most plausible options (if we do anything)  
are to change tlp->tlist or tlist->toks depending on how robust we can  
make the inline functions. Can we be guaranteed that all (what is  
currently now) \tlist_ functions can deal gracefully with # tokens?

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.)

* * *

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.)

Will