Mime-Version: |
1.0 (Apple Message framework v929.2) |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Thu, 6 Nov 2008 19:04:47 +1030 |
Content-Transfer-Encoding: |
7bit |
Content-Type: |
text/plain; charset=US-ASCII; format=flowed; delsp=yes |
Reply-To: |
|
Parts/Attachments: |
|
|
Hello,
Taking a look at how \let:NN and friends are implemented strongly
tempted my "clean up" urge. Rather than delay it for the "big future
refactor" that's going to happen at some stage, I thought it small
enough to address immediately.
(Also, I'm using this public list since I'm not entirely sure that
conducting the expl3 business "in the dark" isn't one of the reasons
that the project has attracted less interest than we possibly would
have liked.)
Here's the offending code:
\def_protected_long_new:Npn \let:NN #1{\let:NwN #1=~}
\def_new:Npn\let:cN #1 {\exp_after:NN\let:NN\cs:w#1\cs_end:}
\def_new:Npn\let:Nc{\exp_args:NNc\let:NN}
\def_new:Npn\let:cc{\exp_args:Ncc\let:NN}
Yielding concerns:
- Why is \let:NN long?
- Shouldn't the variants be protected as well?
- I'd be surprised if \let:cN *really* needs to be hand-optimised,
given the definition of \exp_args:Nc :
\def_long_new:Npn \exp_args:Nc #1#2{\exp_after:NN#1\cs:w#2\cs_end:}
I'd like to propose this change:
\def_protected_new:Npn \let:NN #1 { \let:NwN #1=~ }
\def_protected_new:Npn \let:cN { \exp_args:Nc \let:NN }
\def_protected_new:Npn \let:Nc { \exp_args:NNc \let:NN }
\def_protected_new:Npn \let:cc { \exp_args:Ncc \let:NN }
Any comments?
Cheers,
Will
|
|
|