Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 10:15:05 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7B8F6Qq005182 for ; Tue, 11 Aug 2009 10:15:07 +0200 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 n7B8BYMl006476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 10:11:34 +0200 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 n7B7w6Gq010332; Tue, 11 Aug 2009 10:11:28 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 287164 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 10:11:27 +0200 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 n7B8BREg027985 for ; Tue, 11 Aug 2009 10:11:27 +0200 Received: from pluto.open.ac.uk (pluto.open.ac.uk [137.108.145.32]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7B8BEHf006282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Aug 2009 10:11:17 +0200 Received: from laurel.open.ac.uk ([137.108.170.71]) by pluto.open.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MamRt-0002Sb-N4 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 09:11:13 +0100 Received: from KIELDERCMS1.open.ac.uk ([137.108.140.186]) by LAUREL.open.ac.uk ([137.108.170.71]) with mapi; Tue, 11 Aug 2009 09:11:13 +0100 Thread-Topic: xparse Thread-Index: AcoZ2rAbIyX2vFkCQpae/vnYbEl5wwAgEMjg References: <4A7921CF.5020803@morningstar2.co.uk> <4A7A1505.4040604@residenset.net> <4A7AD930.2090106@residenset.net> <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com> <4A804317.6050909@morningstar2.co.uk> <4A80469B.5040305@morningstar2.co.uk> <4A804ED7.4040305@morningstar2.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id n7B8BREg027986 Message-ID: Date: Tue, 11 Aug 2009 09:11:13 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: "J.Fine" Subject: Re: xparse To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4A804ED7.4040305@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 11 Aug 2009 08:15:05.0465 (UTC) FILETIME=[D531FE90:01CA1A5B] Status: R X-Status: X-Keywords: X-UID: 5873 Joseph Wright wrote: > J.Fine wrote: > >> Sorry, I'm a bit lost! Which bit of the thread are we talking about? > >> (xparse as-a-concept, post-processing arguments, how to specify > >> arguments, ... ) > > > > All of the above, taken together. > > > > One starts with parsing key-value arguments in TeX macros, then further > features are required, and you start adding features to the LaTeX macros > for list processing and the like, and before you know it something has > arise that is too complicated for TeX macros. > > As I see it, the basic idea of xparse is to separate how user functions > expect input (stars, optional arguments, mandatory arguments, etc.) from > how internal functions work (fixed numbers of mandatory arguments). To > do this, the idea is to create \newcommand-on-steroids, so that complex > arguments can be processed. For example, \newcommand can't even make two > optional arguments or look for a star. > > So if we take the common example of \section, the code at present mixes > input syntax and internal workings. The plan would be to replace it with > something like: > > \DeclareDocumentCommand \section { s o m } { > % Code here > } > > where the code always has three arguments #1, #2, #3 to pass down to the > underlying structure. The idea is it is then possible to alter input > syntax without touching most of the code. [snip] There are some interesting ideas here, but why implement them in TeX macros? How will you translate LaTeX documents into XML? Surely to do this you will need a LaTeX->XML translator written in /some other language/. And once you have that, why do you need an implementation written in TeX macros? And come to that, the translator will surely want access to > \DeclareDocumentCommand \section { s o m } { > % Code here > } Perhaps you'll find, when you remove 'TeX macros' from the requirements specification you'll find that it's better not to use TeX macros for the implementation. -- Jonathan The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).