On Fri, Jul 01, 2005 at 10:44:13AM +0200, Hans Hagen wrote:
Heiko Oberdiek wrote:
existing documents can break because of added new primitives.
a small chance; such a package does not know about the primitive; the only danger can be in:
- core latex uses a new primitive - old package overloads overloads new primitive by macro - core latex functionality fails
For example, package foo defines: \newcommand{\match}... and fails with error message. Then we have frequent news groups postings: "After pdfTeX update package foo is not working, ..." or "Error message after pdfTeX update, ..." In the eyes of the readers, pdfTeX is guilty, not the best advertisment for pdfTeX. And in the worst(normal) case author of package foo doesn't have time for an update or cannot be found.
but, for new primitives
With prefixes and reserved namespaces, document and package writers have the chance to avoid name clashes with future versions of pdfTeX. Without is asking for unnecessary trouble.
partially true, what if users have \pdf or whatever as prefix for their own macros?
But users have the chance to know, that there are "reserved" prefixes and can avoid future name clashes, when new primitives are introduced.
as said ... etex introduced primitives that clashed with context (and probably with other stuff around as well; \protected, \expanded, \interactionmode, those \if's etc are all candidates; and yet, we now default to etex as engine)
Perhaps we can ask the etex people, their experience and what they would do.
so ... there is always the danger of a clash; the best we can do is to provide a list of new primitives in a separate file so that users can use that list to parse all their local stuff for clashes.
And they would have to do it again and again for each new version
of pdfTeX that introduces new primitives.
Yours sincerely
Heiko