Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 03:48:03 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n761m14W028121 for ; Thu, 6 Aug 2009 03:48:02 +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 n761hg8J002901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Aug 2009 03:43:43 +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 n75M1saX001169; Thu, 6 Aug 2009 03:43:34 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 284683 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 6 Aug 2009 03:43:33 +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 n761hX5q021285 for ; Thu, 6 Aug 2009 03:43:33 +0200 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n761hSTd007139 for ; Thu, 6 Aug 2009 03:43:32 +0200 Received: by wa-out-1112.google.com with SMTP id n7so90680wag.26 for ; Wed, 05 Aug 2009 18:43:27 -0700 (PDT) Received: by 10.115.107.6 with SMTP id j6mr12475289wam.104.1249523007383; Wed, 05 Aug 2009 18:43:27 -0700 (PDT) Received: from ?129.127.15.244? ([129.127.15.244]) by mx.google.com with ESMTPS id j34sm10649746waf.61.2009.08.05.18.43.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 18:43:26 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-4-632861789; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) References: <4A7921CF.5020803@morningstar2.co.uk> X-Mailer: Apple Mail (2.935.3) X-Spam-Whitelist: Message-ID: <79B867F8-66E2-4E32-BF89-8967B4F58BA3@gmail.com> Date: Thu, 6 Aug 2009 11:13:21 +0930 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Will Robertson Subject: Re: xparse To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4A7921CF.5020803@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: 06 Aug 2009 01:48:03.0152 (UTC) FILETIME=[EF8D7D00:01CA1637] Status: R X-Status: X-Keywords: X-UID: 5820 --Apple-Mail-4-632861789 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 05/08/2009, at 3:38 PM, Joseph Wright wrote: > \DeclareDocumentCommand \foo { o[default] m } % now has a default! Is the syntax to use square brackets or braces? (I thought the latter, which is why I ask. As always, I prefer braces; what if the default is to contain brackets?) Lars mentions that he thinks the optional argument is unnecessary; I'm not fussed either way, but I like the simplicity of being able to write {o m} and having a standard boolean test to check whether it's present or not. > The current xparse implementation lets you create your own specifier > letters. This is probably very risky: what if two packages use the > same > letter? I'd drop this idea. One comment I have here is that in the future I don't see many people defining weird combinations of arguments due to the prevalence of keyval-style argument processing instead. I'd even think about dropping coordinate-style parenthesis input like "(x,y)" based on this. (Which can be emulated easily enough with "d()" and a clist mapping in the input.) On the other hand, I've been keen on the idea of an optional braced argument. If it's an all-or-nothing decision about including marginised option types, then I'd rather keep 'c' and also add 'n' (or whatever) to represent that. Alternatively, I could write a separate package for defining functions to accept a variable number of arguments. We don't need to cram every possible functionality into \DeclareDocumentCommand. > Will has suggested that we should insist optional arguments follow > directly on, with no spaces, to mean that: > > \foo*{arg} % #1 = TRUE, #2 = "arg" > and > > \foo *{arg} % #1 = FALSE, #2 = "*" > > are treated differently. The idea here is that it makes LaTeX syntax > more "regular", useful for translation to other formats. I think he's > right, but wonder how others see it. The current xparse allows both > space-skipping and non-space-skipping tests. I'd certainly say we > should go with only one: either spaces are allowed or they are not. Re-reading your approach in xparse-alt, I believe what is currently implemented there is the best approach. It applies sensible defaults and allows overrides; to whit: {m o} does not skip spaces {m o m} does skip spaces {m !o} does skip spaces {m ^o m} does not skip spaces Since (a) can't always skip spaces, and (b) never skipping spaces leads to inconsistencies, and (c) only need to ignore spaces when the optional argument is last -- I strongly think xparse-alt has it right. Will --Apple-Mail-4-632861789 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGITCCAtow ggJDoAMCAQICECN4qE5kBXLk2f/jVDfSZPwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDEyOTA1NDkxNVoXDTEwMDEyOTA1NDkx NVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQd3Nw cjgxQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL0BeSiAbKuqxeRN p2qn/m8ZL+xawr/WXyPgEF0FipWgRe9l3sMXcFHokcUu0xOc97R7xkUsGcQ8EyybGHuWey6x7X1Y xJZXnoAxqcaG+eREytoYGMIKs6BhEEogLVb2ERw3lQNVnOzanSFeGo8suMAN4zzCtqAjJiA1ph7h 1pksTgECYK5EiIZbFsB6zSDa8crNk404z1CfIA6YO8ezvjbDda+D0r8NU2tq9WS9F5IaG+bW71Ya JegEcSZ+WF6Z+fs2MUMCLLu8n50Er0nuy4dxOmkdMRNfbeaM39dsEwjAAgcQnvPNmlJ215nZWQRH 49YowtSBOYUYq0ZylWRE6x8CAwEAAaMtMCswGwYDVR0RBBQwEoEQd3NwcjgxQGdtYWlsLmNvbTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBABaRP8+PDYpKIRGlFgjs1HvMmJnqu4reSqp+ ulv0zJZIjIbX/sLbIsnecl9nycHfhubPdc+hDfpCqNZ2+NGQHwwoyuDl7KOdTY0BDPp3eJLio7ob EYEr0H8rFwqfx2LWJ0G6nMhNEjLvs7sFKyriSpk++TWJnnsf86xai5m0tlOwMIIDPzCCAqigAwIB AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7 TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRA HmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0P BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG 9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAjeKhOZAVy5Nn/41Q30mT8MAkGBSsOAwIaBQCgggFv MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjAxNDMyMVow IwYJKoZIhvcNAQkEMRYEFCwVEM8AymSRYUdxtliXZS9hevH1MIGFBgkrBgEEAYI3EAQxeDB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk /DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk/DANBgkqhkiG9w0BAQEFAASCAQCZRSuX5qUO25+JYhwS KFyUcA86IA4P1PMu+DaqjAZe04smfMOhRHSFiDB6A/D8D42un1C6EA/Bf0No61BvyBqvAjaaQ7oX 3ZbAJc2r4PmvxHhbNlFfqMH4RPdaBpB7+HD5PhD3vdwPGQ/7bFMkMKtfS3fAg/un814dOaa78wlE JqL7M5DDjj0FR+W1skrhLc7FJxGL3VhrZb0IeBoLIRYgqQro+50cJyQIVVGwKZLBlie2K29amN8v IeLc3ARtB6rsKqXtedn93PlcoZDd3cBUT7eFJ8b/Qrzd98dEcjo8ooI+Bi2qN3hVD51rgpusk8AG z0wqUtfL9EXo/shm0f64AAAAAAAA --Apple-Mail-4-632861789--