Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id q0TDJw0Q026312 for ; Sun, 29 Jan 2012 14:19:59 +0100 Received: (qmail 14642 invoked by alias); 29 Jan 2012 13:19:53 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 29 Jan 2012 13:19:53 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx057) with SMTP; 29 Jan 2012 14:19:53 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id q0TDHkNv010121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 14:17:46 +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 q0T876Pv002175; Sun, 29 Jan 2012 14:17:46 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1935966 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 29 Jan 2012 14:17:46 +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 q0TDHjVj017018 for ; Sun, 29 Jan 2012 14:17:46 +0100 Received: from mail-lpp01m010-f49.google.com (mail-lpp01m010-f49.google.com [209.85.215.49]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id q0TDHeTZ010102 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sun, 29 Jan 2012 14:17:45 +0100 Received: by lagr15 with SMTP id r15so2660216lag.22 for ; Sun, 29 Jan 2012 05:17:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.108.49 with SMTP id hh17mr7242739lab.0.1327843060705; Sun, 29 Jan 2012 05:17:40 -0800 (PST) Received: by 10.152.21.39 with HTTP; Sun, 29 Jan 2012 05:17:40 -0800 (PST) References: Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Whitelist: Message-ID: Date: Sun, 29 Jan 2012 08:17:40 -0500 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Bruno Le Floch Subject: Re: Unexpandability inside \csname To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (BackTrace mail analyze); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnGL2vqOgpaBYL16oitsMrgDt/NQNpSCZFFjDOy 97xb7Zpf+wZnd5ZXNcvLDXR3Wg3wRjdQbwEMh8=V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6995 Hi Will, I hope you are well. > Consider: > > \csname\ifnum 3 > 2 foo\fi\endcsname > > This (probably obviously to all of you) complains with the standard "Missing > \endcsname inserted." presumably because there's an unexpandable implicit > \relax inserted somewhere in there. It doesn't. Implicit \relax are inserted when the conditional is still trying to get the end of its arguments and hits its matching \else or \fi. Here, the rhs of the comparison ends either at "2 " if spaces have catcode 10, or at "2 f" if spaces are ignored (or course, the f is not part of the number). Perhaps you meant \csname\ifnum 3>2\fi\endcsname which indeeds does \csname\relax\endcsname, an error. > In expl3 we've discussed the concept of "restricted expandability", which > refers to an expandable function that doesn't fully expand inside an "f" > function (which is expandable \romannumeral-style expansion). > > Does it make sense to also indicate how/where expandable functions won't > behave correctly inside "c" arguments? I must admit I haven't considered the > ramifications of what these mean entirely. It does seem there's not > necessarily much overlap between the f-unexpandable functions and the > c-unexpandable ones. I believe that all expandable and restricted-expandable functions will behave correctly within a csname, as long as their result is made of characters. For instance, \use:c { \tl_reverse:n { \relax } } would of course not work, but that's not the "fault" of \tl_reverse:n. If we have a problem with csnames, it's that they expand more strongly than x-expansion, hence don't respect protected macros. Cheers, Bruno