1
2
3\startcomponent followinguptex
4
5\environment followingupstyle
6
7\startchapter[title={\TEX}]
8
9\startsection[title={Prefixes}]
10
11The fact that we merged \ETEX, a bit of \PDFTEX\ and some of \ALEPH\ into
12\LUATEX, already makes it a nonstandard \TEX\ engine. In \LUAMETATEX\ we go a
13bit further. Completely outsourcing the backend has the side effect that some
14(extension related) primitives have to be implemented explicitly. The fact that
15\LUA\ is integrated has consequences for, for instance, initialization.
16Defaulting to \UTF8 input makes it different too. And delegating many font
17matters to \LUA\ also doesnt make it behave like good old \TEX.
18
19Here I discuss another difference. One can argue that this definitely makes it
20less \TEX, but in practice this is not that problematic. Were talking prefixes
21here. Traditional \TEX\ has only prefixes:
22
23\startitemize[n]
24\startitem
25 \type {\global}: when used, it will make the next definition a global one.
26 The \type {\globaldefs} parameter can be used to force global or local
27 definitions.
28\stopitem
29\startitem
30 \type {\long}: when applied, this will make a macro bark on a \type {\par}
31 (or its equivalent) when grabbing an argument. In \LUATEX\ this check can be
32 disabled. \footnote {In a similar fashion barking about a \type {\par} in
33 math mode can be disabled. Such warnings made much sense when a \TEX\ run
34 took much time and was triggered and traced on relative slow output devices.}
35\stopitem
36\startitem
37 \type {\outer}: when applied the macro can only be used at the outer level.
38\stopitem
39\stopitemize
40
41Multiple prefixes can be given and their effects accumulate. The \ETEX\ extension
42adds another one:
43
44\startitemize[continue]
45\startitem
46 \type {\protected}: this will make a macro unexpandable inside an \type
47 {\edef}, an \type {\xdef} or token list serialization.
48\stopitem
49\stopitemize
50
51In \CONTEXT\ we never use(d) \type {\outer} and I cant even think of a useful
52application in a large macro package. in \MKII\ most interface macros are defined
53as \type {\long}, and because in \MKIV\ we block the complaints, we dont need
54this prefix either. On the other hand, many macros are defined \type
55{\protected}. \footnote {Or in \CONTEXT\ speak, they are defined as \typ
56{\unexpanded}, because we already had \typ {\protected} as well as \typ
57{\unexpanded} before these were introduces as primitives.}
58
59When you look at the implementation, \type {\long} and \type {\outer} are
60properties of the so called command code: we have normal, long, outer and long
61outer macros, and each has a unique command code. For some reason \type
62{\protected} is not implemented with command codes, which would have doubled the
63number to eight, but as special token injected in front of the macro preamble.
64Using a command code would have made more sense as there is no real speed penalty
65in that, while the special token indicating is a macro (body) is protected now
66has to be intercepted in some cases.
67
68Anyhow, already for a while I wondered if I should drop \type {\long} and \type
69{\outer} (making them noops). I also had on my agenda to promote \type
70{\protected} to a normal command code. And, already for a long time I wanted to
71play with a new prefix: \footnote {This is a typical example of a feature that I
72like playing with, before deciding if it will stay (as such).}
73
74\startitemize[continue]
75\startitem
76 \type {\frozen}: this will protect a macro (for now only a macro) against
77 redefinition, which provides a bit of protection for a user.
78\stopitem
79\stopitemize
80
81Promoting \type {\protected} brings the set of call commands from four to eight,
82and a \type {\frozen} property would bump it to sixteen. This is still okay, but
83in some places it would involve mode testing. However, dropping \type {\long} and
84\type {\outer} would not only keep the set small (just four) but also rid it of
85some tests. There is no performance penalty either (even a bit of gain in case of
86many protected macros as we no longer need to skip the special signal token) and
87it even saves some memory (but not that much).
88
89As a bonus there are a few more conditionals: \type {\ifprotected}, \type
90{\iffrozen}, and, very experimental, \type {\ifusercmd}, which can be used to
91check if something is user defined (often not a primitive). These probably only
92make sense for diagnostic purposes.
93
94In the end, the implementation was not that hard. In the process I also removed
95the \type {\suppress...} parameters so \type {\par} no longer plays havoc. If this
96new prefix \type {\frozen} stays of will affect more definitions, well see.
97
98\stopsection
99
100\startsection[title={Conditionals}]
101
102Another domain where there have been some extensions is conditions. In a previous
103chapter I mentioned \type {\iftok} already. As this is not a manual I will not go
104into details about other new conditionals. For instance we have a few that can be
105used to check for valid dimensions and numbers. This can lead to a bit cleaner
106code, although for instance in \CONTEXT\ we always used support macros for this.
107We seldom needed more than we had but when interfacing with \METAPOST\ it helps a
108little.
109
110Another, maybe interesting one is \type {\ifcondition} which when \TEX\ is in
111jump over branches mode is seen as a valid \type {\if<cmd>} token but when it
112comes to expansion the following macro determines a true or false state. A second
113nice experiment is \type {\orelse} which is to be followed by a valid \type
114{\if<cmd>} token and makes for less nesting which sometimes looks nicer and also
115has some advantages.
116
117I might wrap up these and other extensions in articles once they are considered
118stable and useful. But first Ill test them in real situation, which in practice
119means that \CONTEXT\ users will test them, probably without noticing.
120
121\stopsection
122
123\stopchapter
124
125\stopcomponent
126 |