Mail-Followup-To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
References: <4E6D0C75.6090500@morningstar2.co.uk>
            <20110919104222.4501dbcd@marcin-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20110919104557.GA30040@oberdiek.my-fqdn.de>
Date:         Mon, 19 Sep 2011 12:45:57 +0200
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: Heiko Oberdiek <heiko.oberdiek@GOOGLEMAIL.COM>
Subject: Re: Scratch variables
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <20110919104222.4501dbcd@marcin-desktop>
Precedence: list
Status: R

On Mon, Sep 19, 2011 at 10:42:22AM +0200, Marcin Borkowski wrote:

> Dnia 2011-09-11, o godz. 20:31:01
> Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK> napisa??(a):
> 
> > Hello all,
> > 
> > Currently, provision of scratch variables (such as \l_tmpa_tl) is
> > somewhat inconsistent in expl3. However, it is also not entirely clear
> > if these 'general scratch' variables are really idea in any case. Do
> > people see a general need for these variables, or will most users
> > expect to define their own scratch space in all cases?
> > 
> > (The kernel does not use any of these scratch variables, so they are
> > only intended for third-party use in any case.)
> 
> I do not (yet) use LaTeX3, but I am an author of one LaTeX2e class (not
> distributed yet) and I have to say that I find such scratch variables
> quite useful.  Defining "private" ones in packages is what seems to me
> a waste of resources.

I agree. But the risks should not be forgotten.
Because any can use them, the author of one use case
has to be in full control of the code inbetween.
For example, using \count@ as scratch count register:

\count@=123
\modulo{\count@}{7}
\message{\number\count@}

And now \modulo also uses \count@ as scratch register ...

Sneaky bugs can happen if a scratch variable is used
and changed by several functions at the same time.

Yours sincerely
  Heiko Oberdiek