Received: from mout.gmx.net (mout.gmx.net [212.227.17.22])
	by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id r6M7ufvo014184
	for <rainer@rainer-schoepf.de>; Mon, 22 Jul 2013 09:56:42 +0200
Received:  from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net
 (mxgmx112) with ESMTP (Nemesis) id 0MSISd-1UZJGB025j-00TTKd for
 <rainer.schoepf@GMX.NET>; Mon, 22 Jul 2013 09:56:36 +0200
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 r6M7rsrE003190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Jul 2013 09:53:54 +0200
Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1])
	by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r6M227Y9028572;
	Mon, 22 Jul 2013 09:53:53 +0200
Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with
          spool id 10267024 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 22 Jul
          2013 09:53:53 +0200
Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de
          [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with
          ESMTP id r6M7hr7W011765 for <LATEX-L@listserv.uni-heidelberg.de>;
          Mon, 22 Jul 2013 09:43:53 +0200
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47])
          by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id
          r6M7hhPn029736 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128
          verify=FAIL) for <LATEX-L@listserv.uni-heidelberg.de>; Mon, 22 Jul
          2013 09:43:46 +0200
Received: by mail-wg0-f47.google.com with SMTP id j13so761695wgh.14 for
          <LATEX-L@listserv.uni-heidelberg.de>; Mon, 22 Jul 2013 00:43:43 -0700
          (PDT)
X-Received: by 10.180.13.5 with SMTP id d5mr4548595wic.56.1374479023547; Mon,
            22 Jul 2013 00:43:43 -0700 (PDT)
Received: from [139.222.114.129] (che12-j-wright1.che.uea.ac.uk.
          [139.222.114.129]) by mx.google.com with ESMTPSA id
          z6sm38660865wiv.11.2013.07.22.00.43.41 for <multiple recipients>
          (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul
          2013 00:43:42 -0700 (PDT)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620
            Thunderbird/17.0.7
MIME-Version: 1.0
References: <CACKZBPU39WashARzg94y3YLNM=H78kNaD7ojskwGCOAej-mSGQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID:  <51ECE2AC.7020806@morningstar2.co.uk>
Date:         Mon, 22 Jul 2013 08:43:40 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Propagation of 'global'ness
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CACKZBPU39WashARzg94y3YLNM=H78kNaD7ojskwGCOAej-mSGQ@mail.gmail.com>
Precedence: list
List-Help: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>,
           <mailto:LISTSERV@LISTSERV.UNI-HEIDELBERG.DE?body=INFO%20LATEX-L>
List-Unsubscribe: <mailto:LATEX-L-unsubscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Subscribe: <mailto:LATEX-L-subscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Owner: <mailto:LATEX-L-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Archive: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>
Envelope-To: <rainer.schoepf@GMX.NET>
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-GMX-Antivirus: 0 (no virus found)
X-UI-Filterresults: notjunk:1;V01:K0:kbwbv7VydpE=:bNlLhd+PhiNue4zWs4lt9cbMPM
 xKv+G8wYYbq9IYFf1LC3LyiJF0t/NX1fZuClR4CXfMqObhnRKkKJj3Wov4FHZFaM3ewILRWiB
 gDlhtNJLf085n5YBFpoeUQ6h9mJwXAeXys2aeXzVZvN8LnNKVbz+0CJKa4yu+ErpkBsvfNrH4
 7sq4nPlnEF+3oms80TJyQb7y8r+euRsaluIsLZp8fHzq3ELdlgWyE7e9maxWcX8W9ENLgv7Zb
 357M4+rKyOcOab+YCFW6Zp0kWN4VTW75jaapxlAGHbKvZ4VVt2MJjeIe9UWfZOpveSe6rymqq
 t9JvUVQu+mfBs/wN/tYe06dUMRISYbSBagc4uE6nPscXtLsgvC1lnWrJue7bbB7k10jhKMoKX
 D0JL1Ebs3vcb6Zlk3ytbbWvepmhzioCTZFoqcpwE6prR8yJ9C0cg+kgQsgfcTZYIO3DFCDK4y
 BqrboqYwavat70d5/7+trMUIwixebMU4t3LvImB2Vie0QqxDsTMOh/ebLf0hhgtu9C727/OuI
 /EefkPhafo6GcHuBK0aGHIE0obh6UCRo3d9v3s3WIyxkUhmOGcxQTv/THA81wzkbndHNA3U+x
 2SyoPF8TRrjRiovfZZQ6/MnX/ZVYDaHARrArL5vfC/MICxm/1cZkyOYXkSEdd6iLk+2ODb4Fe
 vqWzjiPir/ajjgHBTk024n9oZ9dBCrO89sDC/vqQszfRmMUW2C8ypsa/sBqsd3aY7zXdlYVEc
 JCpRWMmhJmYEL2OqF0YDt4ZeJLDRCkOoItX6RQkmCz43A+GGbgppfBdi+Ov+i2h1MKUqMCXv0
 Vc9SHWShKWxNN798Qyiw31m9nhPphwFrtVJVCYjCfhkWhrfkQbjPwj7TDmVEQkHzCDifkltl8
 rKe/PidM7yLMIBO/hEup9PXREc4RzI07WTsxOmHXL4Xo8kQMtvKrPHtRECqtHE762EfadlJbY
 8u13a0lVXP+T6vDox+9hsxTbJO1Ib8+XjhiO5YH57SWxSgFVFqhq9T93rcIhXNUS7rPD8R4+K
 QH17UrK3ad0Pyfhbn9UEoDUIpHq/kXGDqGks0vdWDkJAGQKo8fZ2M4cMp3mvGZCPuoNMwQrgK
 mXb6XjHtl82HI51+je+Jp2dmDJ6cPUuuom27KPlJ4HP3QGae+b+noSfa/XTzmnRhmjPpTT2S+
 IWAMzRM2/RxNNSQZVI9jbpQIaVCkntUoTcZY+EKqwYoYKYd/jDkoSXDRRilIcYArCR7rPkXBp
 ficJC3YhX9LiNsoVHoJwcA46ndkfNDOpWf0DPdWCNgMs71vTixWBnuFBisUixzPM0aqrmE1IG
 h40uOo+oa9WwWjC1OhYgDXuWTvnPBc0sWp1GrYwbglKLq+wbob6cSMKjZVMXskKwuv3s1I1xP
 vHdpjDy/SuYjCHg8i9N+uo/Y+ugxWxlckHg4szwYI+dO5oQJLaW4lshL2b7hii1MImA7gGslf
 ecuE3LnQcxnaUYRvDqx2lcCQveJOQt26RaRQBMq4CCnPHGth4hz0UMvDQOwob+2RPi8hv8INO
 xJmTFK+3Au2tkq1UJKSQTXiut4TRgZVIVkv9/YUp1d3tZJzhlTLA55PLmbJVPQ/TsT6MhoPxz
 Uxva+AEq9O9gR8oUCf7ZRrCnLeiglWUA
X-UI-Loop:V01:STyazJe8USE=:DkG7vhbdxncYopp+yCkgIl/5vdLG9dFhunEgTAh42to=
Status: R
X-Status: 
X-Keywords:                  
X-UID: 7271

On 12/07/2013 16:56, Michiel Helvensteijn wrote:
> Hello all,
> 
> It occurs to me, as I write my new expl3 datastructure, that the
> current convention for specifying and propagating 'global'ness of a
> function (namely, by inserting a 'g' in the name somewhere) leads to
> either code duplication or to the definition of boilerplace auxiliary
> functions. It is also too easy to get copy-paste-happy and forget to
> add a 'g' in an implementation somewhere.

Certainly see a point here, but on the other hand I'm not a fan of
encouraging more and more data structures. Writing a full data structure
module is non-trivial: in most cases, I'd expect people to be using
combinations of the existing ones in an ad-hoc fashion for their purpose.

> To encapsulate that detail and to save typing, I furthermore suggest
> that functions like `\cs_new_protected(_nopar)_scoped:NpnNN` are made
> available. To demonstrate their use, I compare the current `\prop_put`
> definitions with the new ones I propose:

This doesn't quite work, as \cs_... should be 'generally for commands',
not just 'for commands that are for variables'. Presumably something
inside \prg_... might be suitable.

> Note that `\tl_sset:NNx` and `\tl_sput_right:NNx` are now spelled out
> in their proper place, so the reader doesn't have to go back and forth
> to understand what's going on. There is no need for auxiliary
> functions and errors of omission are unlikely, since omitting #1 would
> lead to an error.

One of the reasons we decided against auto-detection in some other cases
(I forget exactly where) is that something like \tl_set:Nn can be used
with things that don't follow the naming convention (e.g. user-level
command names). So you can't rely on

  \l_...
  \g_...
  \c_...

for picking up scope. (While we've not worked it through yet, at some
stage we need a document-level token list equivalent, and an interface,
and that will have to use \tl_set:Nn internally, for example.)

I'd also note that 'the reader' should be a small set of people, if we
are doing our job right. The idea is that the docs for expl3 should be
clear enough without people having to read the code. Now, that's not
always true and there are some notable gaps, but I'd hope we can fix
those at the doc. level as people raise them.
--
Joseph Wright