Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 15:36:01 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7SDa0Su003434 for ; Fri, 28 Aug 2009 15:36:01 +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 n7SDX5Qb031370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 15:33:05 +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 n7SACXO2008953; Fri, 28 Aug 2009 15:33:06 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 289126 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 28 Aug 2009 15:33:06 +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 n7SDX6iP023087 for ; Fri, 28 Aug 2009 15:33:06 +0200 Received: from av12-1-sn2.hy.skanova.net (av12-1-sn2.hy.skanova.net [81.228.8.185]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7SDWoEJ031220 for ; Fri, 28 Aug 2009 15:32:53 +0200 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4143C3821E; Fri, 28 Aug 2009 15:10:19 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id E0570381C4 for ; Fri, 28 Aug 2009 15:10:18 +0200 (CEST) Received: from hexley.local (90-230-192-94-no86.tbcn.telia.com [90.230.192.94]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id AD36237E4C for ; Fri, 28 Aug 2009 15:10:18 +0200 (CEST) User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 References: <122D1D66-1300-424C-9FBC-11C0B0CCB6C9@gmail.com> <4A9517EA.208@residenset.net> <7FF23F49-785D-444F-94E0-28498B035A60@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id n7SDX6iP023088 Message-ID: <4A97D80A.4000602@residenset.net> Date: Fri, 28 Aug 2009 15:13:46 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= Subject: Re: template vs template-alt To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <7FF23F49-785D-444F-94E0-28498B035A60@gmail.com> 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: 28 Aug 2009 13:36:01.0757 (UTC) FILETIME=[7BDCB8D0:01CA27E4] Status: R X-Status: X-Keywords: X-UID: 6038 Will Robertson skrev: > On 26/08/2009, at 8:39 PM, Lars Hellström wrote: > >> One remark without having looked at template-alt in detail is however >> that the signatures above feel as though they're on the wrong side of >> the =. That there are two arguments is a property of number-format; >> you need to know this when providing a value for this parameter. The >> :N signature rather seems like it applies to the implementation, the >> details of which are otherwise in the right hand side. > > > The current interface evolved from pgfkeys; I can't say I disagree with > you but I think a simpler scheme might involve a more complex parser. [snip] > Unless any of these jump out at you or you've got some more radical > ideas how to design this interface, I don't think I can see an > improvement over what template-alt currently uses. Well, why use a syntax that needs a separate parser at all? The main reason to have used a key=value syntax in the first place appears to have been the presence of defaults in the right hand side, but with your suggestion of separating the defaults from the basic declaration that loses most of its weight. What remains isn't such a good match to the basic 1-1 correspondence implied by a key=value syntax. Instead of \DeclareTemplate{caption}{lesssimple}{4}{ above-skip .set:N = \l_caption_above_skip , below-skip .set:N = \l_caption_below_skip , number-format .function:N = \caption_number_format:nn , nonumber-format .function:N = \caption_nonumber_format:nn , single-line-format .function:N = \caption_single_line_format:n , caption-font .function:N = \caption_set_font: , caption-hj-setup .instance:nN = {hj} \caption_hj_instance , } -- which is really some kind of pseudo-tabular key.declarationcommand=arguments syntax -- one can let the parameter declaration argument be a sequence of commands (in a sense, give it \declarationcommand{key}arguments syntax), like so: \DeclareTemplate{caption}{lesssimple}{4}{ \Variable {above-skip} {\l_caption_above_skip} \Variable {below-skip} {\l_caption_below_skip} \Function {number-format} {2}{\caption_number_format:nn} \Function {nonumber-format} {2}{\caption_nonumber_format:nn} \Function {single-line-format}{1}{\caption_single_line_format:n} \Function {caption-font} {0}{\caption_set_font:} \Instance {caption-hj-setup} {hj}{\caption_hj_instance} } The \Variable, \Function, and \Instance commands above need not exist in general; they can be locally redefined "within the parameter declarations". (Philologically it is not unheard of in other languages to have special sets of commands available within declaration blocks.) Besides avoiding the overhead of a special parser, the above also has the advantage of being more robust by virtue of simplicity and adherence to the general language syntax and semantics, which tend to have their corner cases better worked out than something invented for a special purpose. Lars Hellström