Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Dec 2008 22:02:28 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id mBUL2Qax020116 for ; Tue, 30 Dec 2008 22:02:26 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id mBUKxN1d031537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 21:59:23 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id mBTN2UUE011969; Tue, 30 Dec 2008 21:59:12 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 230034 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 30 Dec 2008 21:59:12 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id mBUKxCai032393 for ; Tue, 30 Dec 2008 21:59:12 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id mBUKx8qd031456 for ; Tue, 30 Dec 2008 21:59:11 +0100 Received: from morse.mittelbach-online.de (p54A83D2B.dip.t-dialin.net [84.168.61.43]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LHlgC0BGa-000218; Tue, 30 Dec 2008 21:59:08 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id B680765BD7; Tue, 30 Dec 2008 21:59:04 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <495160FA.8000004@morningstar2.co.uk> <9EECA5EE-12A7-4C01-8311-7658BD3E8E04@gmail.com> <21363E65-E3FB-4495-A94E-6789AC0619A0@gmail.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1/YZ+GT4+s5pFlkputKCkimXMXrDrbzATCpWOk gHf0YQre7987iNyDHxsR+dsmZ1zfQStazZjRhNZtF2PpoTC2Bp deFx1PKw13BjUtM962JUTE0ANE88bbv X-Spam-Whitelist-Provider: Message-ID: <18778.35736.43421.950797@morse.mittelbach-online.de> Date: Tue, 30 Dec 2008 21:59:04 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Back to "token list" nomenclature; was Re: \tlist_if_eq:nn To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <21363E65-E3FB-4495-A94E-6789AC0619A0@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.464 () BAYES_00,FORGED_RCVD_HELO,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.64 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 30 Dec 2008 21:02:28.0335 (UTC) FILETIME=[EC5A67F0:01C96AC1] Status: R X-Status: X-Keywords: X-UID: 5553 some random thoughts here: a) in reality both toks and tlps store precisely the same thing namely arbitrary token lists: there is no distinction whatsoever in that respect, ie whatever you store in a toks is something you can store in a tlp. The difference is "how you have to put it into the toks or the tlp" b) so the technical difference is really only in the way the functions put something into the storage bins: toks accept any balanced token list while tlps require any # to be doubled on input. c) the other important difference is how you get something out of the bin: with tlps you can simply use the pointer and that is really the normal usage (the \tlp_use:N is really syntactic sugar) while with toks you absolutely need the accessor in every case. because of c) we need different names for the containers even though the content is really the same (a)). because of b) the use of # together with tlps isn't really advisable. you do get anything in if you know your input, but you can only process it further in a very limited fashion (and only if you don't know what's in there that is). So my proposal for tlps is that we document they support balanced token lists not containing #. we can add a footnote saying that technically that is only an approimation of the truth and that the reality is ... but that we recommend that this feature is not to be used or only in places where the author is in full control of the processing and the input. A followup question then is d) what exactly do we want to support in the input stream, ie on the level of the functions currently called \tlist... Morten said he wrote those with the idea in mind that they should accept arbitrary balanced token lists similar to toks. If we can do this reliably (and want to) then, yes, we should probably call them \toks_... Personally I'm not sure we can do that reliably in the end (assuming more functions pop up where we want to build an inline version operating on the input stream) and I don't really think it is necessary. Dealing/messing with stray # is something that really necessary only in the inner parts of the kernel, but such things should not appear on aribtrary levels and if they do then by the end of the day they will blow in your face (even if one step before you managed to surive. So I personally would go KISS and offer functions that limit the accepted input to balanced token lists without #. cheers frank