Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 10:07:13 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n8G878OC026217 for ; Wed, 16 Sep 2009 10:07:08 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n8G831AW011403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2009 10:03:02 +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 n8FM22Wg007861; Wed, 16 Sep 2009 10:02:52 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 311325 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 16 Sep 2009 10:02:52 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n8G82q93009207 for ; Wed, 16 Sep 2009 10:02:52 +0200 Received: from ueamailgate02.uea.ac.uk (ueamailgate02.uea.ac.uk [139.222.131.185]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n8G82Y0F009612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Sep 2009 10:02:38 +0200 Received: from ueams02.uea.ac.uk (ueams02.uea.ac.uk [139.222.131.131]) by ueamailgate02.uea.ac.uk (8.13.1/8.13.1) with ESMTP id n8G82YG6017033 for ; Wed, 16 Sep 2009 09:02:34 +0100 Received: from [139.222.202.92] by ueams02.uea.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MnpTE-0004r9-Bj for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 16 Sep 2009 09:02:32 +0100 User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 References: <4AA21B30.8030509@morningstar2.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Canit-CHI2: 0.00 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, outgoing) X-CanItPRO-Stream: UEA:outgoing (inherits from UEA:default,base:default) X-Canit-Stats-ID: 30661321 - f27f9cdf5144 X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 X-Scanned-By: CanIt (www . roaringpenguin . com) on 139.222.131.185 Message-ID: <4AB09B99.10508@morningstar2.co.uk> Date: Wed, 16 Sep 2009 09:02:33 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: l3keys revision To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4AA21B30.8030509@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 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 16 Sep 2009 08:07:13.0513 (UTC) FILETIME=[B2C2D590:01CA36A4] Status: R X-Status: X-Keywords: X-UID: 6097 Joseph Wright wrote: > Hello all, > > The ongoing template discussion has prompted me to think again about > some aspects of l3keys. It's pretty clear to me that the aims in l3keys > are rather different from those in template. l3keys is really about > creating keys for the programmer, so it can take a very different > approach to template. > > Several things have come up in the discussion, and I'd like to see how > other people feel about the following before doing anything: > > - I added .initial:n and .initial:V mainly with template in mind. In > l3keys, initial values can be set using \keys_set:nn, and overall I feel > this is probably clearer (separate key definition from key setting). I'd > therefore like to drop .initial:n/V > > - There is .function:N which again was more about template than l3keys. > I'm not sure the property is actually very clear (it does \cs_set:Nn > { > - There are currently a .code:n and a .code:Nn property, where the > former only takes one argument and the later takes N. To be honest, I > think it might be better to only have .code:n so that if further > splitting of a value is needed it is done elsewhere, and not by l3keys. > > - Related to the .code:Nn point, .generate_choices:nn also splits the > value part of a key-value argument in two. I'm no longer sure this is a > good thing, so perhaps > .choice_code:n = , > .generate_choices:n = > would be better. > > - Not everyone likes the .set:N idea of detecting the variable type and > scope from the variable name, rather than having .tl_set:N, .int_gset:N, > etc. As we are talking about a programmer function, it's not > unreasonable to read the variable information from the name. It's easy > to go back to the previous method if that is the consensus. > > I'd like to get this sorted out soon (i.e. in the next week) as I am > using l3keys for siunitx v2 and as Manuel has indicated he is also > looking at using l3keys for real work. I've made the changes outlined above. At present, I've retained .set:N and added - .dim_(g)set:N - .int_(g)set:N - .skip_(g)set:N - .tl_(g)set:N - .tl_(g)set_x:N Is everyone OK with retaining .set:N in this way, or would others prefer only to have the explicit setting properties? I'd like to update the CTAN version soon to reflect these changes (which I hope are the final ones for l3keys), and so want to get this right. -- Joseph Wright