LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 19 Sep 2011 20:43:37 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
Am 18.09.2011 14:57, schrieb Ulrike Fischer:
> Am Sun, 11 Sep 2011 20:31:01 +0100 schrieb Joseph Wright:
>
>> 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?
>
> Well on the one side I still feel the urge to avoid to waste
> ressources.

that shows how long you work with TeX I guess ;-)  --- we oldtimers do 
have this urge, don't we?

> But on the other side at soon as user input is involved
> it can get difficult to be sure that code from other packages don't
> meddle with the scratch variables. So actually I use them only
> seldom.

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 somehting 
first), but for proper packages it is far better come up with your own 
private scratch names.

If you think about: if every package needs, say, 10 scratch variables of 
some sort, and a document load 20 packages, then you blow away a total 
of 200 names/registers.

With as minimum of eTeX as the underlying engine you have how much of 
those? thousands. and even if the higher registers are not precisely as 
performant as the first 256 allocated, for most documents you will never 
ever exceed them and even if.

Fact is, as Heiko pointed out, a lot of the subtle bugs in package and 
kernel interaction in 2.09 and 2e have been due to reusing things like 
\count@ \next etc and then suddenly creating dependencies that much 
later bombed out very unexpectedly

frank

ATOM RSS1 RSS2