Content-Type: multipart/signed; boundary=Apple-Mail-4--993728593; 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>                                 
            <DB76B425-0A88-43B4-9CF0-B92FAF159E37@gmail.com>                   
            <4A7AD930.2090106@residenset.net>                      
            <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com>           
            <4A804317.6050909@morningstar2.co.uk> <4A80508F.3030904@elzevir.fr>
            <0C83E480-14E3-4CD8-924E-3B9EA602E004@gmail.com>
            <4A810D6E.5050207@morningstar2.co.uk>
Message-ID:  <13962923-07A3-4C66-B144-E728DBC10183@gmail.com>
Date:         Wed, 12 Aug 2009 11:54:54 +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:  <4A810D6E.5050207@morningstar2.co.uk>
Precedence: list
Status: R

--Apple-Mail-4--993728593
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi,

Going back to an earlier message, and taking a little step back. Sorry  
for the long message.

On 11/08/2009, at 3:49 PM, Joseph Wright wrote:

> Will Robertson wrote:
>>
>>   \DeclareDocumentCommand \foo { ?{\my_sanitise:n} } {
>>     % do whatever \foo is supposed to do with #1
>>   }
>>
>> I neglected to include how \my_sanitise:n would actually be  
>> written. And
>> I'm not too sure about that. If it ends up that \my_sanitise:n has to
>> write to a scratch variable anyway, then I'm not sure we've saved  
>> too much.

[...]

> In any case, I'd imagine any post-processor being a function of one
> argument. Internally, they'd do something with a temporary variable,
> then put the value of the variable back into the input of the  
> underlying
> function defined by <code> in \DeclareDocumentCommand.

So how would \my_sanitise:n above be written? If it's not expandable,  
then the results of modifying #1 must be written to a standard scratch  
variable (right?). At which stage I'm not convinced we've saved any  
confusion over the original way to write this sort of thing.

For example:

\cs_set:Nn \my_sanitise:n {
   \tl_set:Nn \l_scratch_tl {#1}
   \tl_replace_in:Nnn \l_scratch_tl {&} {&amp;}
   % but what to do now with \l_scratch_tl ??
}

If it's easier to hook post-processing steps into the argument stage  
but *harder* to write the functions that do so, have we gained much?  
Enough to justify the initial increase in complexity?

Maybe to re-write my concern; how could we simplify this example from  
xdoc2l3: (use as much hypothetical syntactic sugar as you like)

\gdef\XD@gp@intrange#1#2#3\XD@endgrab#4{%
    \count@=#4\relax
    \ifnum #1>\count@
       \PackageError{xdoc2l3}%
         {Too small! Changed to minimum value #1}\@ehc
       \count@=#1\relax
    \else\ifnum #2<\count@
       \PackageError{xdoc2l3}%
         {Too large! Changed to maximum value #2}\@ehc
       \count@=#2\relax
    \fi\fi
    \expandafter\XD@gh@put \expandafter{\expandafter{\the\count@}}{#3}%
}
\gdef\XD@pgp@intrange#1#2{%
    \XD@macro@prepend\@tempa{\XD@gp@intrange{#1}{#2}}%
    \XD@parse@processor
}

In my opinion, based on this example, it will be easier for users of  
xparse to write their own argument-parsing functions as nested  
definitions inside \DeclareDocumentCommand than to write something  
like the above. Notice the number of necessary but implicit macros  
that the author must know about:

   \XD@gp@...
   \XD@pgp@...
   \XD@endgrab
   \XD@gh@put
   \XD@macro@prepend\@tempa
   \XD@parse@processor

To be clear, I'm not yet opposed to this style of argument processing  
and I *do* think there are some simplifications that can be made to  
the code above to make it more palatable for users to write.

But before we agree to include such complex ideas into what is now a  
simple package (for end-users, I mean), I think it would be good to  
verify that a distillation of xdoc2l3 will "fit" into the philosophy  
of xparse.

*  *  *

After I say that, I suppose it would be remiss of me to go away  
without actually mentioning how I think the ideas in xdoc2l3 might  
work in xparse(-alt).

First of all, I think we should drop the idea of using more letters  
for shorthands. As we've discussed, each package will use different  
letters and clashes will occur very quickly.

Secondly, for simplicity let's drop the idea of toks-grabbing as a  
proxy for argument grabbing.

Thirdly, use actual function names rather than character strings to  
represent argument processors.

 From xdoc2l3, there seem to be two broad cases for argument processing:
     \argumentprocess{#1}
and
     \argumentprocess#1<delimiter>

These can be referred to in the argument definitions as something like
     >\CS
and
     @\CS{DELIMITER}
where \CS is the processing function and DELIMITER is what's inserted  
after the argument, in the second case.

Finally, allow these to be chained together if necessary, as in  
something like this: (\foo takes one argument)

\DeclareDocumentCommand \foo {
   @\foo_split_colons:n{::\q_nil} >\foo_range_check:nnn m
}{...}

Open questions:

1.  Does this cover the functionality that you miss from xparse in  
xdoc2l3?
2.  Is it simple enough for xparse?
3.  Assuming that we must deal with both expandable and unexpandable  
argument processing, is there a straightforward way we can write the  
argument processors? (E.g., see how boolean expressions are written in  
expl3; a consistent interface is used for both expandable and  
unexpandable tests.)
4.  Does that end up being any easier than writing things by hand?

I've got some sort of niggling concern that this approach mixes "how  
the arguments are parsed" with "what the structure of the arguments  
are", which xparse is more careful not to do.

*  *  *

Now I really must get back to work :)

Will
--Apple-Mail-4--993728593
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
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxMjAyMjQ1NVow
IwYJKoZIhvcNAQkEMRYEFKIK/Pg3zrxn8ySe15e6Wx5ayIrwMIGFBgkrBgEEAYI3EAQxeDB2MGIx
CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk
/DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk/DANBgkqhkiG9w0BAQEFAASCAQA8Fi4HMSrgxfCyESNz
VcU8zlSXMhL7QqF7zR7GH3taC3azIk3LDrYSmQ29NRykDg3RQTmvRqBUHVM/fp5AJqp8mTYv4UKq
6zyTVROdr23Yn5b4eatJkUJcrc+d+FoovTulJ5cNr3hdiBaeaHd+Vf5D/YJMtRQ7j9k5PcKwtiEN
iL53X8+9Zs4OqeDlTlXwbixLSfdsVT1dclE/T+2CztPahKzgqB/WzV0eJxiGEaoMjMRve/0NhEL7
TXPhOiIqpGfSmCJqJ6p2Jqub79fB/W2/1yVRS/RXFVuKt8l5x4jq8CqCj+i9w7jjZDGUUn4Vmob7
JSHNoKgbHKP2sFTn46bAAAAAAAAA

--Apple-Mail-4--993728593--