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 p2LKAJvo021991 for ; Mon, 21 Mar 2011 21:10:20 +0100 Received: (qmail 16825 invoked by alias); 21 Mar 2011 20:10:14 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 21 Mar 2011 20:10:13 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx025) with SMTP; 21 Mar 2011 21:10:13 +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 p2LK7dQb029628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 21:07:40 +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 p2LHgd6F004135; Mon, 21 Mar 2011 21:07:29 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1351104 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 21 Mar 2011 21:07:29 +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 p2LK7TxO009943 for ; Mon, 21 Mar 2011 21:07:29 +0100 Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.213.177]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p2LK7NjK029475 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 21 Mar 2011 21:07:28 +0100 Received: by yxh35 with SMTP id 35so4130031yxh.22 for ; Mon, 21 Mar 2011 13:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.72.162 with SMTP id t22mr5818315yhd.218.1300738043670; Mon, 21 Mar 2011 13:07:23 -0700 (PDT) Received: by 10.147.113.12 with HTTP; Mon, 21 Mar 2011 13:07:22 -0700 (PDT) References: <905C5ED0-6639-4DEB-95AC-A2FCB2C4491D@gmail.com> <935A1EA2-C971-4A3A-8DF4-6F890E0CFB32@gmail.com> <5256FD2C-CD53-4FF0-A405-5B8B2781E5EC@gmail.com> <19843.17637.935263.780194@morse.mittelbach-online.de> <19843.47932.785350.652072@morse.mittelbach-online.de> <7F71B7CB-A004-49DC-B178-D9CF58DA93A2@gmail.com> <08C15662-D17F-41A5-9709-CE0C244BF398@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Whitelist: Message-ID: Date: Mon, 21 Mar 2011 16:07:22 -0400 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Bruno Le Floch Subject: Re: expl3's seq_pop_right etc. To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <08C15662-D17F-41A5-9709-CE0C244BF398@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDtMgfETrECMLUO9erHzOJe7j3G660N4yBY6XHH YPYtmQj6mbYUTZ3LnaFANLWrKE7/wIDhnv+VrW0hxOapLRUwuY9oBqo5h+Dh9B42XlFTMTKlXDju GaV8Q==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: 6699 >> Another question I noticed is whether mappings should be made nestable >> or not. I _think_ that \seq_map_function:NN is nestable, and that >> \seq_map_inline:Nn and \seq_map_variable:NNn are not. All three can be >> made expandable, I believe. Should they? > > Indeed they should. > I ran into this problem just the other day and left a note to come back to > this issue :) I'll do that tomorrow (there is a typo above, I mean "All three can be made _nestable_"). > I've actually wondered if \seq_show:N is really needed at all, but we've > never come up with a good enough argument to drop it completely in favour of > \seq_display:N. > > I've updated a small handful of test cases to use \seq_display:N instead, > but there are many more examples that use \meaning (etc.) that probably need > adjusting. In fact, quite a few tests are \prop_display:N with a prop whose items are seq, so we can't use \seq_display:N for that. These will remain to be changed when/if we switch. > It's just a few in xor, right? I think, yes. > Looking in say \xor_save_area_info:n, I'm a bit confused by what it does: does the content of, e.g., \g_xor_area_DDD_float_seq have to be fully expanded? Otherwise \cs_set_nopar:Npx \@tempa { \exp_not:N \int_gset:cn {g_xor_area_ #1 _float_int} {\int_use:c {g_xor_area_ #1 _float_int} } \gdef \expandafter\noexpand \csname g_xor_area_#1_float_seq \endcsname {\csname g_xor_area_#1_float_seq\endcsname} } can be replaced by \cs_set_nopar:Npx \@tempa { \exp_not:N \int_gset:cn {g_xor_area_ #1 _float_int} {\int_use:c {g_xor_area_ #1 _float_int} } \gdef \exp_not:c {g_xor_area_#1_float_seq} { \exp_not:v {g_xor_area_#1_float_seq} } } which just unpacks \g_xor_area_#1_float_seq. That would be simpler. > perhaps all it needs is for \seq_elt:w > and \seq_elt_end: to be \protected, and then their reassignment to \relax > could be avoided. Haven't tried, though. Right. The default (i.e. the value when not inside a mapping) could be \cs_set_protected:Npn \seq_elt:w #1 \seq_elt_end: {\ERROR} \cs_set_eq:NN \seq_elt_end: \tex_relax:D and in the new scheme, \cs_set_protected:Npn \seq_elt:n #1 {\ERROR} But I don't like relying on a default value to be in effect for those \seq_elt... because there is too much risk that something goes wrong (e.g. the value is not restored after a mapping and you end up mapping instead of doing nothing). Also I would prefer the mapping to gobble its argument and raise an \ERROR, so that the error recovery is better: \cs_set:Npn \seq_elt:w #1 \seq_elt_end: {\ERROR} \cs_set:Npn \seq_elt:n #1 {\ERROR} Regards, -- Bruno