Bernd Raichle wrote:

Hi Taco,

I'm not on the NTG pdfTeX list (Rolf has forwarded your mail to the ExTeX Developers list), thus I am replying directly. It is up to you to forward my mail to the list ...

Added the ntg-pdftex list in CC (but I am not on extex-devel so this may get confusing).

...

\ifprimitive <csname>

True if the <csname> has the same meaning as it would in initex, (but gives an error if <csname> is currently undefined).

Ok. What is the result for a non csname, incl. active characters? I assume false.

I was thinking about issuing an error message, but Hans has convinced me that returning false is more usable than an error. So it will be false, even though it is clearly a user error to ask for the primitive- ness of something that can not possibly be a primitive.

...

\executeprimitive <csname>

Executes the primitive that would be known as <csname> in initex, even if the <csname> is currently undefined or defined to mean something else. Raises an error if there is no matching internal command (of course).

Is \executeprimitive expandable or non expandable? Or does it depend on the "expandability" of <csname>?

Either unexandable or dependant on the <csname>, but definately not fully expandable (mainly because of the can of worms in your example).

...

These are quite straightforward, and I do not assume this needs much discussion. But the next ones are related to "if feature ...", and those are bit harder to define.

I propose to make it possible to 'predefine' primitives in the executable. All program code is completely ready, except that the hash table entry is never created, making it impossible to use that primitive in initex without extra work.

A similar effect would be possible if (pdf)TeX has something like name spaces. The predefined primitives can then reside in the namespace "internal" and can be made available by importing the symbols from the internal to the current namespace.

That is what Heiko hinted at as well, and here is how I responded: Heiko said:

It needs some thinking. First thoughts: * It looks like a first step to a real namespace implementation, a (perhaps read-only) internal namespace, namespaces for extensions, and user/package macros. Why not going further then?

Taco replied:

TeX's current internal structure does not allow a clean solution, so if we want true namespaces in TeX, we probably have to start thinking about a successor to pdftex. Otherwise, we would need to redesign the whole symbol table / token handling while trying to remain 100% compatible. That sounds like a nightmare to me.

These last 4 primitives I proposed are an attempt to come up with something that works next month (as opposed to next year), but you are right that it probably needs more thinking, anyway.

Back to Bernd's current e-mail:

Mmmh, what is the result when existing csnames are "overwritten" by \expose... or when the meaning of an internal csname is assigned to another csname by \let and then obscured?

In general, if a macro progammer wants to be irresponsible, I'm not going out of my way to stop them from doing so. However, some of the more blatant user errors are easy to catch and I therefore propose to make them illegal from the start: \exposeinternal does not accept already defined <csname>s and \obscureinternal always makes the <csname> undefined

Here are some test cases ...

\def\internalcommand{Hi!} \begingroup \exposeinternal\internalcommand

A totally new error message is issued. Possibly ! Currently defined control sequence. \internalcommand ->Hi! But in this case perhaps even a stronger restriction is needed: ! Not at top level.

\obscureinternal\internalcommand \show\internalcommand

*\show\internalcommand

\internalcommand=undefined.

\begingroup \exposeinternal\internalcommand \global\let\x=\internalcommand \endgroup \show\x

*\show\x

\x=\internalcommand.

This is why the prefix is "obscure" instead of "undefine"

\exposeinternal\internalcommand \let\x=\internalcommand \obscureinternal\internalcommand \show\x

\x=\internalcommand.

\exposeinternal\internalcommand \def\x{\internalcommand} \obscureinternal\internalcommand \show\x

\x=macro: ->\internalcommand.

\x

! Undefined control sequence. \x ->\internalcommand

Best wishes, -bernd