[NTG-pdftex] [ pdftex-Patches-466 ] \primitive and \ifprimitive

noreply at sarovar.org noreply at sarovar.org
Tue Oct 17 15:16:26 CEST 2006


Patches item #466, was opened at 2006-01-07 21:52
You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

Category: Primitives
Group: v1.40.0
Status: Closed
Resolution: Accepted
Priority: 4
Submitted By: Taco Hoekwater (taco)
Assigned to: Martin Schröder (oneiros)
Summary: \primitive and \ifprimitive

Initial Comment:
This patch implements two new primitives:

  \primitive \par

This will run the 'primitive' command \par, even if it 
has been re- or undefined in the meantime. \primitive
is not expandable, because it may be asked to execute
unexpandable primitives as well as expandable ones.

If you supply a nonexistant primitive, it will be 
ignored (no error is raised).

The second primitive is a new type of \if:

  \ifprimitive \par ... \else .. \fi

returns true if the current meaning of \par is the
'primitive' command \par.


The patch is against alpha-20051226, i hope that is not 
too old (?). I expect to do at least one minor update 
during the beta cycle, after the pdftex code is 
flattened. It was quite a struggle to make this 
change file work ok, and as a result, there are 
a few ugly web hacks.


----------------------------------------------------------------------

Comment By: Nobody (None)
Date: 2006-10-17 18:46

Message:
Logged In: NO 

> This patch implements two new primitives:
> \primitive \par 

This wording is very misleading : \par is not a new
primitive, and should not be mentioned here.  Its place (if
it has one) should be under examples of possible usage. 
Presumably the second new primitive is \ifprimitive, which
occurs much later in the prose.

Regarding the expandability or otherwise of \primitive, the
very worst of all worlds would be "making the expandability
depend on the referred primitive"; a primitive should either
be expandable or not expandable, not vary its behaviour
according to the phase of the moon !

----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros)
Date: 2006-07-26 15:57

Message:
Logged In: YES 
user_id=421

This has been included in version 1.40

----------------------------------------------------------------------

Comment By: Bernd Raichle (bernd)
Date: 2006-02-14 12:47

Message:
Logged In: YES 
user_id=3344

IMHO it would be better to rephrase the above to (and change
the implementation accordingly :-():

<quote mode="changed">
\primitive is expandable, because it may asked to execute
expandable primitives as well as unexpandable ones.

\primitive<cs> will expand to one token, the original TeX
primitive.  This token will then be processed further as usual.
</quote>


If \primitive is left unexpandable, a lot of programming
techniques seems to be unavailable, e.g., all redefined
expandable primitives in expandable-only context.

Or any assignment to the get the original primitive, like

\edef\orignumber{\expandafter\noexpand\primitive\number}

\expandafter\let\expandafter\orignumber\primitive\number


Sidenote: The new \primitive seems to implement a subset of
a full-blown namespace mechanism.  If (pdf)TeX would have
namespaces, one simply has to access the appropriate token
within the "primitive" namespace (e.g. \primitive::number to
 access the original \number primitive, assuming the
notation \<namespace>::<csname>).  How about choosing an
appropriate namespace mechanism for (pdf)TeX and
implementing it instead?

----------------------------------------------------------------------

Comment By: Taco Hoekwater (taco)
Date: 2006-02-13 23:26

Message:
Logged In: YES 
user_id=1608

We need to think about this. 

I see your point, but making \primitive expandable forces
the introduction of un-redefinable tokens, and that has its
own problematic side-effects (like slowing down each and
every definition). I welcome third opinions on whether the 
benefits outweigh that downside.

At one point I tried making the expandability depend on the
referred primitive, but that gave me headaches at the
implementation stage (a pity, because that would have been
nice).

Yet another solution is to have an expandable command as
well as an unexpandable command (two primitives instead of
just the single \primitive).

On the side note: I will happily write an implementation ...
but only if someone comes up with a specification that works
under all conditions instead of only under specific
programming styles :-)



----------------------------------------------------------------------

Comment By: Bernd Raichle (bernd)
Date: 2006-02-13 22:10

Message:
Logged In: YES 
user_id=3344

IMHO it would be better to rephrase the above to (and change
the implementation accordingly :-():

<quote mode="changed">
\primitive is expandable, because it may asked to execute
expandable primitives as well as unexpandable ones.

\primitive<cs> will expand to one token, the original TeX
primitive.  This token will then be processed further as usual.
</quote>


If \primitive is left unexpandable, a lot of programming
techniques seems to be unavailable, e.g., all redefined
expandable primitives in expandable-only context.

Or any assignment to the get the original primitive, like

\edef\orignumber{\expandafter\noexpand\primitive\number}

\expandafter\let\expandafter\orignumber\primitive\number


Sidenote: The new \primitive seems to implement a subset of
a full-blown namespace mechanism.  If (pdf)TeX would have
namespaces, one simply has to access the appropriate token
within the "primitive" namespace (e.g. \primitive::number to
 access the original \number primitive, assuming the
notation \<namespace>::<csname>).  How about choosing an
appropriate namespace mechanism for (pdf)TeX and
implementing it instead?

----------------------------------------------------------------------

You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106


More information about the ntg-pdftex mailing list