Content-Type: multipart/signed; boundary=Apple-Mail-5-635436615; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v935.3)
References: <4A7921CF.5020803@morningstar2.co.uk>
            <4A7A1505.4040604@residenset.net>
Message-ID:  <DB76B425-0A88-43B4-9CF0-B92FAF159E37@gmail.com>
Date:         Thu, 6 Aug 2009 11:56:16 +0930
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A7A1505.4040604@residenset.net>
Precedence: list
Status: R

--Apple-Mail-5-635436615
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi Lars,

On 06/08/2009, at 8:55 AM, Lars Hellstr=F6m wrote:

> I should perhaps point out that I've also explored some variations =20
> on the xparse theme (Jan 2008, in a package I called xdoc2l3 -- see =
http://abel.math.umu.se/~lars/xdoc/)=20
> , but back then I didn't get much response to the questions that =20
> required *decisions* (and then I got distracted by other projects). =20=

> I will mention the issues I recall at suitable locations below.

I'm afraid that I agree with Joseph that regardless of the technical =20
merits of xdoc2l3, the approach it takes sacrifices some measure of =20
simplicity for flexibility. And even with the flexibility we run into =20=

the problems of TeX itself -- sure, we can change catcodes, but only =20
if it's not nested within an argument. And even if we use \scantokens, =20=

% still kills things.

> Optional arguments of argument specifiers?!? My feeling is that =20
> optional, star-type, etc. arguments should be considered user-level =20=

> syntactic sugar, and that the programming APIs should rather stick =20
> with mandatory arguments and signals like \NoValue. =20
> \DeclareDocumentCommand could be user-level enough that optional =20
> arguments make sense, but there is the alternative of having it be
>
> \DeclareDocumentCommand \foo { o{\NoValue} m }
>    % Optional argument with no default (returns \NoValue)
> \DeclareDocumentCommand \foo { o{default} m }
>    % now has a default!
>
> Recall that \newcommand and friends require you to specify a default =20=

> value for the optional argument whenever there is one.

The one advantage I can see to allowing { o m } is that there is then =20=

a standard technique for testing with \IfNoValueTF, rather than having =20=

package authors write things like
    ... { o{\q_nil} m }
        { ... \quark_if_nil:NTF #1 {}{} ... }
which mean the same thing but look different.

>> The current xparse implementation lets you create your own specifier
>> letters. This is probably very risky:  what if two packages use the =20=

>> same
>> letter?  I'd drop this idea.
>
> Agreed. An analogy with array package definitions of new column =20
> specifiers fails because there it is usually the document author who =20=

> would make the definition, thus confining the definition to code =20
> under the control of that author, whereas with xparse it would be =20
> arbitrary package authors that don't have such confinement.

Double agree. Good argument.

>> Thinking about catcode-sensitive input, most cases can be handled =20
>> by the
>> e-TeX tools we have available. For true verbatim input, that =20
>> obviously
>> does not work, but I feel that truing to "crowbar" verbatim input =20
>> xparse
>> is a mistake.  Almost all user functions are not verbatim, and the
>> particular issues for those that are, I think, better handled by =20
>> hand.
>> (The way that xparse works means that it absorbs arguments before
>> passing them to the code you program.)  I also suspect that xparse
>> handling of verbatim will never be reliable enough for general use.
>
> Is that a yes or no to my "harmless character sequences"? These can =20=

> handle data like URLs which might prompt people to go verbatim, but =20=

> they aren't implemented using \catcode changes.

Not sure I understand -- even URLs need to sanitise % if they're used =20=

within an argument.


>> Finally, the question about expandability of \IfNoValue has been =20
>> asked
>> before.  As \DeclareDocumentCommand only ever makes \protected
>> functions, I don't think we need to worry.
[snip]
> a great advantage of \NoValue is that it can be passed around =20
> without syntactic difficulties, so the actual test might happen in a =20=

> distant helper macro or even completely separate from the \foo =20
> command (if the argument is stored away in a token list). Finally, =20
> you're thinking too imperatively about the whole thing, thus =20
> discarding the possibility of performing such tests at expand-only =20
> time.

No real comment about this. I agree with Joseph that if everything is =20=

protected then the expandability of \IfNoValue becomes less important.

> Other possible xparse features I'd like to see discussed (and recall =20=

> right now) are:
>
> * The ability to preprocess (e.g. evaluate as a calc expression)
>   an argument before handing it to the command body.

Since expl3 functions allow you to evaluate calc expressions anyway, =20
what advantage would there be to this?

> * The ability to have arguments assigned to token lists rather
>   than handed as macro parameters (lets one get around the 9
>   parameter limit).


If we attempt to keep things simple, then I think this is stretching =20
the limits of what we'd like \DeclareDocumentCommand to achieve. =20
Besides, I've never seen an argument for when >9 arguments are =20
actually necessary that couldn't be implemented in some other way =20
(e.g., keyval or csv list).

I think a goal for xparse should be simplifying the majority of =20
approaches taken by package writers, and leave the esoteric stuff to =20
continue to be implemented by hand.

Will=

--Apple-Mail-5-635436615
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
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwNjAyMjYxNlow
IwYJKoZIhvcNAQkEMRYEFJM+YmJSVrv0hcl/S1aCkOqBC4JeMIGFBgkrBgEEAYI3EAQxeDB2MGIx
CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk
/DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk/DANBgkqhkiG9w0BAQEFAASCAQBFQT7L0qnfKeQv7pZa
EuXn9CAIF3/kw5HR15hxYiJxQ6nW8Rl8E7xmA3YonpEgcmK1nNqg0mVfdXoDUez75P37ay07ZAh/
+eA7QK0gaozeWNdeUHMUPIpG1FUz8/ShGWc6IlC7cTyW8EnL1PY78egaWys/3iJ4FzTBg9cbnDUL
w3GUSahZl2XKN76cHxbGM+W/FeSFIum9dMVSJgqsk/f+J9mXp2NYs0bi2dVqUQQ4Cj3qmTTYHzYZ
QpmDxZGiuI0/O7fsmBgUNX2WZpA2GFv3rcj97zPZYqWuVQWeSmDKMzpGhQeiEh/n1vbiutqgyIgg
a066gC0XYipkk2mNyYyTAAAAAAAA

--Apple-Mail-5-635436615--