Fwd: [NTG-pdftex] \ifprimitive and \ifinternal/\iffeature (design
taco at elvenkind.com
Tue Jul 5 17:32:10 CEST 2005
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:
> 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?
> 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
\obscureinternal always makes the <csname> undefined
> Here are some test cases ...
A totally new error message is issued. Possibly
! Currently defined control sequence.
But in this case perhaps even a stronger restriction is needed:
! Not at top level.
This is why the prefix is "obscure" instead of "undefine"
! Undefined control sequence.
> Best wishes,
More information about the ntg-pdftex