Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 14:50:32 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id mAHDoU1v013955 for ; Mon, 17 Nov 2008 14:50:31 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id mAHDlScN010672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 14:47:28 +0100 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 mAGN3B8f023342; Mon, 17 Nov 2008 14:47:21 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 149945 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 17 Nov 2008 14:47:21 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id mAHDlKaM001994 for ; Mon, 17 Nov 2008 14:47:20 +0100 Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.251]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id mAHDlHT7001114 for ; Mon, 17 Nov 2008 14:47:21 +0100 Received: by rv-out-0708.google.com with SMTP id c5so2497900rvf.10 for ; Mon, 17 Nov 2008 05:47:15 -0800 (PST) Received: by 10.140.204.7 with SMTP id b7mr2253267rvg.11.1226929635412; Mon, 17 Nov 2008 05:47:15 -0800 (PST) Received: from ?10.0.1.100? (122-49-160-236.ip.adam.com.au [122.49.160.236]) by mx.google.com with ESMTPS id f42sm6467575rvb.6.2008.11.17.05.47.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 05:47:13 -0800 (PST) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v929.2) References: <859ec5630811060730t6d8689t43ec0af09a23b911@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Spam-Whitelist: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id mAHDlKaM001995 Message-ID: <887A8F9F-D139-4C9A-B150-759DDB4AB514@gmail.com> Date: Tue, 18 Nov 2008 00:17:07 +1030 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Will Robertson Subject: Re: Some implementation details of \let:XX To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <859ec5630811060730t6d8689t43ec0af09a23b911@mail.gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.64 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 17 Nov 2008 13:50:33.0032 (UTC) FILETIME=[75DDBC80:01C948BB] Status: R X-Status: X-Keywords: X-UID: 5441 On 07/11/2008, at 2:00 AM, Morten Høgholm wrote: > Question is if you want to have the non-NN variants to be protected. > If you do, then funny things can happen expansion-wise if you have > active characters in the c-argument. Case in question: An active > character appears in the c-argument (say, a colon in a reference > label). If such a character uses the \ifincsname feature to turn > normal in critical places, this will not kick in if \let:cN is > protected and you can wind up with some strange things in place. If > the functions are non-protected, they will perform argument expansion > as usual and then stop once \let:NN is met. Is this actually useful in practise? I'm trying to put some tests together and I'm a bit stumped. I haven't done too much expansion control in restricted contexts, so forgive any trivial cases I'm overlooking. I'm thinking out loud here; some of the following might be rather obvious in hindsight. I'm assuming we've got something like \def\expanded#1{\edef\tmp{#1}\tmp} in which all the "funny stuff" is going on, since it's the only expansion environment I can think of (in my tired state) where we would be worried about the "c" argument being expanded in the wrong context. So if I write something like \def\tmpa{abc} \def\tmpz{xyz} \expanded{ \let:cc{tmpa}{tmpz} } this expands, sort of, to \exp_args:Ncc\let:NN{tmpa}{tmpz} then \let:NN\tmpa\tmpz then \let:NN abc xyz which is obviously bad news. At least any active characters are indeed expanded "correctly" in a csname or whatever. But that seems to be little comfort, when everything else is being expanded when it doesn't make sense. What I'm trying to ask, I guess, is: is there enough expansion control "built-in" to \exp_args: to justify the argument above about \let:cN ? I'm not arguing against not protecting the "c" variants, but at the same time I'm a bit confused how they might be used. Will