User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2)
            Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
References: <4E6D0C75.6090500@morningstar2.co.uk>                      
            <13xqgkr6dq2cr.dlg@nililand.de>           
            <4E778D59.4090105@latex-project.org>           
            <49096BC7-82D6-4DC4-841F-6E7AB70A354A@gmail.com>
            <4E7A33B6.4000701@latex-project.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E7A3A27.7080706@morningstar2.co.uk>
Date:         Wed, 21 Sep 2011 20:25:27 +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: Scratch variables
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4E7A33B6.4000701@latex-project.org>
Precedence: list
Status: R

On 21/09/2011 19:57, Frank Mittelbach wrote:
> Am 20.09.2011 05:57, schrieb Will Robertson:
>> On 20/09/2011, at 4:13 AM, Frank Mittelbach wrote:
>>
>>> I think bottom line we don't really need them any more these days.
>>> The only reason why I would keep them is that for fast access to
>>> variables when experimenting/developing (without needing to declare
>>> something first), but for proper packages it is far better come up
>>> with your own private scratch names.
>>
>> I agree with this, but I don't think we should remove anything that's
>> been around for a while now. I suggest removing the just-added clist
>> scratch variables and keeping what remains as they are -- but not
>> adding any others.
> 
> my takeaway is actually different. I would suggest to keep the tmp
> variables and provide for each datatype exactly two/four default ones
> (also for the new types)
> 
> \l_tmpa_int
> \l_tmpb_int
> \g_tmpa_int
> \g_tmpb_int
> 
> In the general documentation we might explain the issue and risks and
> that we suggest to carefully consider in packages for general use to
> define "private" scratch variables instead, and that those here here for
> convenience as some people prefer this style of programming.

I'm with Frank on this: there is not really a problem with providing a
small number of scratch variables. So the only question is how many. At
the moment, we've got 'mainly tow, a and b'. Seems reasonable to be
going on with.
--
Joseph Wright