Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t6E8h9r5020617 for ; Tue, 14 Jul 2015 10:43:10 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx007) with ESMTPS (Nemesis) id 0Lj64M-1YhEsa3UwY-00dEAC for ; Tue, 14 Jul 2015 10:43:03 +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 t6E8fdPO021012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 10:41:39 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t6E8aX3X010504; Tue, 14 Jul 2015 10:41:39 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 12370846 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 14 Jul 2015 10:33:06 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t6E8X5CZ019825 for ; Tue, 14 Jul 2015 10:33:05 +0200 Received: from aso-006-i434.relay.mailchannels.net (aso-006-i434.relay.mailchannels.net [23.91.64.115]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t6E8WuNr027752 for ; Tue, 14 Jul 2015 10:33:02 +0200 X-Sender-Id: netnames|x-authuser|joseph.wright@morningstar2.co.uk Received: from smtp3.easily.co.uk (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 259F31207D5 for ; Tue, 14 Jul 2015 08:32:49 +0000 (UTC) X-Sender-Id: netnames|x-authuser|joseph.wright@morningstar2.co.uk Received: from smtp3.easily.co.uk (smtp3.easily.co.uk [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Tue, 14 Jul 2015 08:32:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: netnames|x-authuser|joseph.wright@morningstar2.co.uk X-MailChannels-Auth-Id: netnames X-MC-Loop-Signature: 1436862770669:1938598294 X-MC-Ingress-Time: 1436862770669 Received: from [139.222.114.154] (port=50971 helo=[139.222.114.154]) by smtp3.easily.co.uk with esmtpa (Exim 4.43) id 1ZEvdr-0000hd-4E for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 14 Jul 2015 09:32:43 +0100 References: <11lm3sqjz6xux$.dlg@nililand.de> <5595661F.1070304@morningstar2.co.uk> <55962878.5030204@morningstar2.co.uk> <55A4A8D2.6060304@morningstar2.co.uk> <1bc6qigbj7juc.dlg@nililand.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AuthUser: joseph.wright@morningstar2.co.uk Message-ID: <55A4C92A.5030606@morningstar2.co.uk> Date: Tue, 14 Jul 2015 09:32:42 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: Order of key declarations To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <1bc6qigbj7juc.dlg@nililand.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:IER6khR4Fac=:NwkG+bG6FYRPphn2AsYPYcCL9c 285GjkmaFTPFPDSXguDjh5bxLugTxmcs2omhEaT29XRaCq7vUktcC4ezirruMjfjgU0H+6e2k 5fDsTrBVrRCDuULPThbmYQxt6Gq5X+U6wsW5vBTT1N/HSWqbHy3FtpgSK1RcPyFk12Zwsz/yD Onine2UL5a36UYlmCFDOmIwrKjHvNowqvNqf5MeSx58SoFRxVMjFVznm9Gwfg6jy00aRI7ku2 xANmVFhUhB2pCTm7kK+aHWy3mnzfrZed7BMIMf5syIS32dY9D9Y75tMoMn1rX4x5XEqV3EmTi w5+LxdDfybAC1pmc+oLP8B3AiUWtJym1QVNhLXzqDBlkqcuy9KDCZwMd3DmhpMcEM+K+Ccs/0 ro1WNP4eg9em+rgDufe/SlrNEVo66jQqXrP8FTX53tf0vyEUe6G+miAApuE279aFrHgvPjrBB +ioFluqO81rDnrVAojOhcD1SzwloBKyHFW1ck/u21bO0W2utb+PrsL0XQV2LK0uGh86MwS+PP Y6mDJCb0U1BghrNXeyBB74g3wMpOjmWZuEmlj0T6EvIrgpDuk+cHpcJo0wJ1Yb3jBxBCX4U8P k3t40aLphJ+hg+a7/GZ+L9fLLueNB6c8B5grL1u/9rrXtCYCKTAVIG6Hs2gJYMFA8YQhHzhzL llNS2pkiMd+6x6Pxrn5XsGbuhuUF2L1r4wAUqVyngyPWslfmozLQG2TM3MyaLA/EUA6/ZAsjp DDIOUD7GCYc+Dq4eLk/DLG5zBGdAJCbMHuYX57zWMJJGu62SYKtf/EihhvTqm6VKDdKWdzAy3 lrIN5fiO+VMfU1oGoDa0oPFR5wAD9/zqpVaWBzQoDn03HEodUJS0w4QSnpQ6T6zV61HjIDkgS debmbjXYKB3Sbg8kmEhfP8qlKdHImG3r2mKm2j0UvRyiH2CyotgDiftaA5/64sd2vKB7JiMaX qK7AbW49yqSHkJVuj8vmEChCcuj6qMrmAL3B+4npo3BSIyyQnIe0utoO+CrrTumSIkyD2YOfW CXBNAvjBm6C7/XOqXv/3fUlGCkB9nVJojxOBaBsFTlbICy3QjzVEiu4Banoh58xYyFX79Dx9+ 7S0fIUuFhXPlq8ApCPHLaOTDgtZ5eyz5QKr7ZCGXlD3Eap31Q4ONwfT1mbPVw2zxcEIl2sduQ ZKhm2euObk0t2S3aLAxlqobKTJZFn19e+VSS43Z3J6sj6w5VALE+rTYGxvyloVAd8yPR60jPR djMGxA4DUpmIITQcktyjkfbN28t/d5NS+O6wHZUyJhotGXKqfF1M9CdRW/aZap9dUmNwAWq4F Mnuw4oV+bkWVFs3Dj36GfwHPcpZNdiHfuPMxXV9kT/rhEM9O1TLQwL92l1JhJHIDItSalgj6Z fEjq+Fe7yowjY6EMsTopLvjq2iv/CUcrRvwoA1KKTUgRbE6kiBkaxh+oLgJxLlGnmPWNb/J9c 7F0HwJPendxOk4EVvFOuky0su6Jowpba8V4B2GOHniRYroqxoe/GB8f0gFRMDELJZtEq+qlw= = X-UI-Loop:V01:yI4FB7teL4Y=:CtsBq3kd6qqS8x5z47XF2wqNLw8lGCsi54SxYLciXC4= X-UI-Out-Filterresults: notjunk:1;V01:K0:yrFPMLpZVwc=:YM1K8O+Krzrw5ZcPwQ8gTf /FsYakw90gWYJro9tuNhkDyca2OitKaasZuUzLLWpv1FJ7Myg5plFOqMEsV2MpGTDxUQCCbVP XkxhMPyaEm+TiPgePeULyjJpvw4p/sbS6H19JE8SbELno4lcmx/U6PnGRNuiK+lbEscEJcRwJ N2iz/9gTIN31e2G2O04h5TDM9mYa09GeIuQiRSuXMGIVEg+qEK0ee1eAKDvqSBL4bGArSTX/Y TS/hLXeemN1r0UfJ/RFrjqpBUr/3lbwhKBM8b5kMFDEANkJoXZZPfJrw7sG8IdAFPI/EswxFv RIfukxV/0EasaMCjzAsrDFFed4D48jgVZPAkqThM8Q0jSSqjxxMootvw2MUk23mW7DX6oiEWx yGMMagvcjVgcLKz87mRUji57pHWgVlI9coz9iYlCDxS0iJHicyXYlf7TorT9ZuNgeyAAcomBv OAM25GjWrMO4BW/sl+etzDpPDQhMkgtsj3gE9zyVX404sMV6BXJQ X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Status: R X-Status: X-Keywords: X-UID: 7768 On 14/07/2015 09:13, Ulrike Fischer wrote: >> The .default:n is different: an empty default is not the same as no >> default at all (as a default means effectively a value is always given). > > In many cases it is. E.g. I could see not difference with the > .code:n or .tl_set:N. And even choice keys works without a default: > > \documentclass{article} > \usepackage{expl3} > \begin{document} > \ExplSyntaxOn > \keys_define:nn {test} > { > testa .code:n = {the~argument~is #1!}, > testb .tl_set:N = \l_test_tl, > testc .choice:, > testc / .code:n={xxx}, > } > > \keys_set:nn {test} {testa,testb,testc} > > \tl_if_empty:NTF\l_test_tl{~empty}{not empty} > > \ExplSyntaxOff > > \end{document} > > But .default:n={} wouldn't work with bool. I'll take a look over the code: I was actually thinking of the interaction between a default and a value being required, but it doesn't seem to work the way I thought it should! >>> - the action can be reset by setting a new action. >> >> True, and again I will clarify docs. >> >>> Missing is ".value_not_required:" and ".value_not_forbidden:". >> >> I wonder if best would be to deprecate current .value_required: and >> .value_forbidden: and go to .value_required:n and .value_forbidden:n >> taking boolean values? > > Imho it would be more logical to use booleans. But deprecating > things is naturally always difficult ... We have a clear mechanism to make changes: we know that expl3 is still developing and there are areas that simply haven't been tested a lot. I'll go with the change here. >>> Missing is an explicit ".unknown:", which would e.g. allow to remove >>> choices from a key. An accompayning ".known:" which reactivates the >>> key would be interesting too. (I don't know if the code allows >>> this). > >> As previously noted, making a key unknown removes the code behind it >> entirely. Unless there is a compelling use case I'm minded to leave this. > > If there is an .undefine: action it should be possible to remove a > choice with testkey / choicea .undefine:, so an .unknown: is not > really needed. > >> Based on the fact that as far as possible the key property names follow >> other expl3 things (see .tl_set:N, etc.) I will probably go with >> .undefine:, although .unknown: would also fit nicely with the way keys >> are described. > > For me ".unknown:" is a property, ".undefine:" an action. If code > is destroyed I would use the second. That also occurred to me: .undefine: it is. > Side remark: Did you saw this question on tex.SX: > http://tex.stackexchange.com/questions/254878/mactex-2015-running-much-slower-than-mactex-2014/254946#254946 > > I wonder what the expl3 code of mhchem is doing there. It looks like > very long recursions ... A quick look suggests the author has decided to use the regex engine for some parsing. I can see the attraction in a complex situation like mhchem but at the same time no-one is going to pretend that it's designed for speed. Probably I'd stick in a similar situation with using lower-level constructs. (I have something similar in siunitx, where it's clear that all of the number parsing needs to be carefully examined to get the best speed out of TeX, expl3 or not.) -- Joseph Wright