Content-Type: multipart/signed; boundary=Apple-Mail-3--904822255; 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>
            <4A81C3D2.9040607@residenset.net>
            <4A826F15.8050606@morningstar2.co.uk>
Message-ID:  <FEF49696-D7DB-4A35-9D3E-F19D97A19802@gmail.com>
Date:         Thu, 13 Aug 2009 12:36:40 +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:  <4A826F15.8050606@morningstar2.co.uk>
Precedence: list
Status: R

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

Hi all,

I'll try to keep this brief; I've done my usual mistake of writing =20
what's in my head and not impedance-matching it with what's in =20
everyone else's. I'm skipping most of the discussion which I broadly =20
agree with or don't think needs further discussion and jumping =20
straight to the good bits.


Joseph Wright wrote:
> Lars Hellstr=F6m wrote:
>> Nice to see more people joining the discussion.
>
> Of course, provided in the end we can all reach a decision we can at
> least live with. Different people have very different visions, it =20
> seems.

I think we're all approximately on the same page :)


On 12/08/2009, at 10:26 PM, Lars Hellstr=F6m wrote:
>
> The confusion saved is that one can make do with one scratch =20
> variable that is private to xparse, instead of having several that =20
> might have unclear sharing patterns.

I think I prefer this than to use an explicit argument. That is, write
     ... <do some stuff>\toks_set:Nn \l_xparse_result_toks =20
{<results>} ...
rather than
     ... <do some stuff>\toks_set:Nn #1 {<results>} ...

> but that's untested (modification in e-mail of definition of x). =20
> Also, I think "@" would be better than "?"; then @ would mean "drop =20=

> out to more general mechanism for this" at both the argument =20
> specifier and processor level.

Yep, the '?' was partially to indicate I didn't care on the symbol :)


>> Secondly, for simplicity let's drop the idea of toks-grabbing as a =20=

>> proxy for argument grabbing.
>
> Not sure what you refer to here.

Sorry, I'm being unclear again. I just meant that I think we can drop =20=

the =3D{} type processing from xdoc2l3 that don't use #1, #2, ..., but =20=

rather named toks to refer to arguments.


On 13/08/2009, at 5:03 AM, Joseph Wright wrote:

> Lars Hellstr=F6m wrote:
>
>> (The functionality of the above
>> \constrain_to_intrange:nnNn could be a candidate for inclusion into
>> xparse, but \MakeHarmless probably isn't.)
>
> I'm not sure \constrain_to_intrange:nnNn quite fits my idea of
> post-processing. I'm thinking of it mainly for standardising input
> rather than error-checking. However, that is a problem for rather =20
> later,
> I think. If we can get the "basics" sorted, this type of thing can be
> finalised later.

The good thing about these argument post-processors is that we don't =20
have to define *any* in xparse. I agree with Lars' sentiment that you =20=

don't need to give them single-letter names when you can describe what =20=

they do with functions. (While also providing single-letter names for =20=

the very most common ones.)


Lars Hellstr=F6m wrote:
>
> For the record, the syntax I'd currently prefer for that is
>
>  {
>    @{ @{\preprocessorb} @{\preprocessora} O{default} }
>    m o m
>  }

For the sake of argument, assume that we're paring down the =20
functionality of xdoc2l3 to only this and nothing more. (Is that a =20
reasonable assumption?) While I understand where this one comes from, =20=

do you think at this level that it makes sense to use @ for both for =20
"bracing" and for "preprocessor defining"? I think I'd be more =20
comfortable with something like any of the following:

1.    { m @{ >{\preprocessorb} >{\preprocessora} m } o m }
2.    { m  { >{\preprocessorb} >{\preprocessora} m } o m }
3.    { m  [ >{\preprocessorb} >{\preprocessora} m ] o m }
4.    { m    >{\preprocessorb} >{\preprocessora} m   o m }

If technically possible, I #4 is actually the clearest by virtue of =20
being the simplest. If the latter syntax is not technically possible, =20=

I'd prefer to optimise the syntax for the case of a single =20
preprocessor, I think. Writing
     { @{ @{\preproc} m } }
is somewhat cumbersome. A simplification to
     { >{\preproc} m }
would work well even if example #4 above can't work.

Best regards,
Will=

--Apple-Mail-3--904822255
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
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgxMzAzMDY0MVow
IwYJKoZIhvcNAQkEMRYEFP8QzznVZ0lhlA55B5lsk7el4eVAMIGFBgkrBgEEAYI3EAQxeDB2MGIx
CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk
/DCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQQIQI3ioTmQFcuTZ/+NUN9Jk/DANBgkqhkiG9w0BAQEFAASCAQBdMZhaK0C34AY43r1f
Yy0THNX4RIlJhMEM+iJaL2YewejGNNg8qBuB/VCePFAWZ8vNYFoVeKYFirrtn83Shr/FDGGCJvuT
n9lRfXvWQXZrE4RmHq2AD7k20H+2kqTeLzHXCTExwMy0UsqzJq1Mf9zEgcnh0E6XbkyGRu8IySKM
SMFvJk/QCWNnKiv8h3cvpbymZneGanif7nGmbCYnJM8G1rqqIRMvruO7nUUZEUN7H4gdq5YeagqP
Tx0YAV9o4tFRU6yRWyBsV2M6TFIKXDGdRfzJJcfmW2kJCR8o3+vGLcNXtlesQO5Kmd0o+xN0oVn6
41Yg7mCYP7PKMjyOpH9rAAAAAAAA

--Apple-Mail-3--904822255--