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
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0
Content-Type:
text/plain; charset="UTF-8"
Date:
Wed, 27 Feb 2019 06:25:36 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
Content-Transfer-Encoding:
quoted-printable
Message-ID:
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
From:
Kelly Smith <[log in to unmask]>
Parts/Attachments:
text/plain (47 lines)
> in the early days of TeX that was in fact a big headache and there are 
> still a lot of traces in 2e where we tried so save individual tokens 
> like using \@plus (one token) to "plus" (4). Same for registers, when 
> there were less than 255 available for general use.

Yes, I’ve seen those, along with the several numerical constants.

> However with the current limits it doesn't seem at all likely that you 
> could actually hit a boundary.

I looked at the log after running a test document that loaded many large
packages, and, even then, only a small portion of the available csnames
and registers were used. I probably should’ve tried that test first!

>> Would it be a worthwhile effort to conserve both csnames and registers
>> by reusing some variables across template implementations for the same
>> object type, or would it be better to stick to the convention of having
>> completely independent sets of variables for each implementation, and
>> wait to see if it becomes a concern later on?
> 
> On the whole I would say no, because if you do that then you need add a 
> lot of extra code to ensure that nested objects do not accidentally 
> overwrite stuff before it has been  used successfully. This is is still 
> a possible headache if you nest the same type of objects, of course, but 
> then that is immediately clear to the programmer that the code must 
> account for that. If basically arbitrary code uses the same registers or 
> variables then the problem is much worse.

I very much agree with you. I wonder if it’d be a good idea to update
the wording in interface3 of the sections documenting public scratch
registers to indicate that dedicated variables should be preferred for
production code.

Though, I now find myself a bit confused about how TeX handles csnames.
I remember reading somewhere on tex.SX that there tend to be many hash
collisions, but given that TeXLive provides, by default, a hash table
of 615,000 entries, I think it’d be awfully difficult to have any
collisions at all, especially when the average document may use less
than 25,000 csnames.

I suspect that the table isn’t actually that big, but 615,000 is just
the maximum number of csnames allowed. I haven’t been able to confirm
or deny that yet, but I’ve probably been looking at the wrong parts of
the sources files.

—Kelly

ATOM RSS1 RSS2