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:
Tue, 19 Feb 2019 12:40:30 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (33 lines)
Hi  Kelly

> Normally, each template implementation has its own set of variables.
> This certainly keeps things separate but means that a single object
> type may end up with dozens of variables allocated for use by its many
> particular implementations. Although this is not an issue at the
> moment, I wonder if it might be in the future, when templates are used
> extensively.

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.

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

> 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.

frank

ATOM RSS1 RSS2