about-calls.tex /size: 24 Kb    last modification: 2023-12-21 09:43
1% language=us
2
3\startcomponent about-calls
4
5\environment about-environment
6
7\startchapter[title={Calling Lua}]
8
9\startsection[title=Introduction]
10
11One evening, on Skype, Luigi and I were pondering about the somewhat
12disappointing impact of jit in \LUAJITTEX\ and one of the reasons we could come
13up with is that when you invoke \LUA\ from inside \TEX\ each \type {\directlua}
14gets an extensive treatment. Take the following:
15
16\starttyping
17\def\SomeValue#1%
18  {\directlua{tex.print(math.sin(#1)/math.cos(2*#1))}}
19\stoptyping
20
21Each time \type {\SomeValue} is expanded, the \TEX\ parser will do the following:
22
23\startitemize[packed]
24\startitem
25    It sees \type {\directlua} and will jump to the related scanner.
26\stopitem
27\startitem
28    There it will see a \type +{+ and enter a special mode in which it starts
29    collecting tokens.
30\stopitem
31\startitem
32    In the process, it will expand control sequences that are expandable.
33\stopitem
34\startitem
35    The scanning ends when a matching \type +}+ is seen.
36\stopitem
37\startitem
38    The collected tokens are converted into a regular (C) string.
39\stopitem
40\startitem
41    This string is passed to the \type {lua_load} function that compiles it into
42    bytecode.
43\stopitem
44\startitem
45    The bytecode is executed and characters that are printed to \TEX\ are
46    injected into the input buffer.
47\stopitem
48\stopitemize
49
50In the process, some state information is set and reset and errors are dealt
51with. Although it looks like a lot of actions, this all happens very fast, so
52fast actually that for regular usage you don't need to bother about it.
53
54There are however applications where you might want to see a performance boost,
55for instance when you're crunching numbers that end up in tables or graphics
56while processing the document. Again, this is not that typical for jobs, but with
57the availability of \LUA\ more of that kind of usage will show up. And, as we now
58also have \LUAJITTEX\ its jitting capabilities could be an advantage.
59
60Back to the example: there are two calls to functions there and apart from the
61fact that they need to be resolved in the \type {math} table, they also are
62executed C functions. As \LUAJIT\ optimizes known functions like this, there can
63be a potential speed gain but as \type {\directlua} is parsed and loaded each
64time, the jit machinery will not do that, unless the same code gets exercised
65lots of time. In fact, the jit related overhead would be a waste in this one time
66usage.
67
68In the next sections we will show two variants that follow a different approach
69and as a consequence can speed up a bit. But, be warned: the impact is not as
70large as you might expect, and as the code might look less intuitive, the good
71old \type {\directlua} command is still the advised method.
72
73Before we move on it's important to realize that a \type {\directlua} call is
74in fact a function call. Say that we have this:
75
76\starttyping
77\def\SomeValue{1.23}
78\stoptyping
79
80This becomes:
81
82\starttyping
83\directlua{tex.print(math.sin(1.23)/math.cos(2*1.23))}
84\stoptyping
85
86Which in \LUA\ is wrapped up as:
87
88\starttyping
89function()
90    tex.print(math.sin(1.23)/math.cos(2*1.23))
91end
92\stoptyping
93
94that gets executed. So, the code is always wrapped in a function. Being a
95function it is also a closure and therefore local variables are local to this
96function and are invisible at the outer level.
97
98\stopsection
99
100\startsection[title=Indirect \LUA]
101
102The first variant is tagged as indirect \LUA. With indirect we mean that instead
103of directly parsing, compiling and executing the code, it is done in steps. This
104method is not as generic a the one discussed in the next section, but for cases
105where relatively constant calls are used it is fine. Consider the next call:
106
107\starttyping
108\def\NextValue
109  {\indirectlua{myfunctions.nextvalue()}}
110\stoptyping
111
112This macro does not pass values and always looks the same. Of course there can be
113much more code, for instance the following is equally valid:
114
115\starttyping
116\def\MoreValues {\indirectlua{
117    for i=1,100 do
118        myfunctions.nextvalue(i)
119    end
120}}
121\stoptyping
122
123Again, there is no variable information passed from \TEX. Even the next variant
124is relative constant:
125
126\starttyping
127\def\SomeValues#1{\indirectlua{
128    for i=1,#1 do
129        myfunctions.nextvalue(i)
130    end
131}}
132\stoptyping
133
134especially when this macro is called many times with the same value. So how does
135\type {\indirectlua} work? Well, it's behaviour is in fact undefined! It does,
136like \type {\directlua}, parse the argument and makes the string, but instead of
137calling \LUA\ directly, it will pass the string to a \LUA\ function \type
138{lua_call}.
139
140\starttyping
141lua.call = function(s) load(s)() end
142\stoptyping
143
144The previous definition is quite okay and in fact makes \type {\indirectlua}
145behave like \type {\directlua}. This definition makes
146
147% \ctxlua{lua.savedcall = lua.call lua.call = function(s) load(s)() end}
148% \testfeatureonce{10000}{\directlua  {math.sin(1.23)}}
149% \testfeatureonce{10000}{\indirectlua{math.sin(1.23)}}
150% \ctxlua{lua.call = lua.savedcall}
151
152\starttyping
153\directlua  {tex.print(math.sin(1.23))}
154\indirectlua{tex.print(math.sin(1.23))}
155\stoptyping
156
157equivalent calls but the second one is slightly slower, which is to be expected
158due to the wrapping and indirect loading. But look at this:
159
160\starttyping
161local indirectcalls = { }
162
163function lua.call(code)
164    local fun = indirectcalls[code]
165    if not fun then
166        fun = load(code)
167        if type(fun) ~= "function" then
168            fun = function() end
169        end
170        indirectcalls[code] = fun
171    end
172    fun()
173end
174\stoptyping
175
176This time the code needs about one third of the runtime. How much we gain depends
177on the size of the code and its complexity, but on the average its's much faster.
178Of course, during a \TEX\ job only a small part of the time is spent on this, so
179the overall impact is much smaller, but it makes runtime number crunching more
180feasible.
181
182If we bring jit into the picture, the situation becomes somewhat more diffuse.
183When we use \LUAJITTEX\ the whole job processed faster, also this part, but
184because loading and interpreting is more optimized the impact might be less. If
185you enable jit, in most cases a run is slower than normal. But as soon as you
186have millions of calls to e.g.\ type {math.sin} it might make a difference.
187
188This variant of calling \LUA\ is quite intuitive and also permits us to implement
189specific solutions because the \type {lua.call} function can be defined as you
190with. Of course macro package writers can decide to use this feature too, so you
191need to beware of unpleasant side effects if you redefine this function.
192
193% \testfeatureonce{100000}{\directlua  {math.sin(1.23)}}
194% \testfeatureonce{100000}{\indirectlua{math.sin(1.23)}}
195
196\stopsection
197
198\startsection[title=Calling \LUA]
199
200In the process we did some tests with indirect calls in \CONTEXT\ core code and
201indeed some gain in speed could be noticed. However, many calls get variable
202input and therefore don't qualify. Also, as a mixture of \type {\directlua} and
203\type {\indirectlua} calls in the source can be confusing it only makes sense to
204use this feature in real time|-|critical cases, because even in moderately
205complex documents there are not that many calls anyway.
206
207The next method uses a slightly different approach. Here we stay at the \TEX\
208end, parse some basic type arguments, push them on the \LUA\ stack, and call a
209predefined function. The amount of parsing \TEX\ code is not less, but especially
210when we pass numbers stored in registers, no tokenization (serialization of a
211number value into the input stream) and stringification (converting the tokens
212back to a \LUA\ number) takes place.
213
214\starttyping
215\indirectluacall 123
216    {some string}
217    \scratchcounter
218    {another string}
219    true
220    \dimexpr 10pt\relax
221\relax
222\stoptyping
223
224Actually, an extension like this had been on the agenda for a while, but never
225really got much priority. The first number is a reference to a function to be
226called.
227
228\starttyping
229lua.calls = lua.calls or { }
230lua.calls[123] = function(s1,n1,s2,b,n2)
231    -- do something with
232    --
233    -- string  s1
234    -- number  n1
235    -- string  s2
236    -- boolean b
237    -- number  n2
238end
239\stoptyping
240
241The first number to \type {indirectluacall} is mandate. It can best also be a
242number that has a function associated in the \type {lua.calls} table. Following
243that number and before the also mandate \type {\relax}, there can be any number
244of arguments: strings, numbers and booleans.
245
246Anything surrounded by \type {{}} becomes a string. The keywords \type {true} and
247\type {false} become boolean values. Spaces are skipped and everything else is
248assumed to be a number. This means that if you omit the final \type {\relax}, you
249get a error message mentioning a \quote {missing number}. The normal number
250parser applies, so when a dimension register is passed, it is turned into a
251number. The example shows that wrapping a more verbose dimension into a \type
252{\dimexpr} also works.
253
254Performance wise, each string goes from list of tokens to temporary C string to
255\LUA\ string, so that adds some overhead. A number is more efficient, especially
256when you pass it using a register. The booleans are simple sequences of character
257tokens so they are relatively efficient too. Because \LUA\ functions accept an
258arbitrary number of arguments, you can provide as many as you like, or even less
259than the function expects: it is all driven by the final \type {\relax}.
260
261An important characteristic of this kind of call is that there is no \type {load}
262involved, which means that the functions in \type {lua.calls} can be subjected to
263jitting.
264
265\stopsection
266
267\startsection[title=Name spaces]
268
269As with \type {\indirectlua} there is a potential clash when users mess with the
270\type {lua.calls} table without taking the macro package usage into account. It not
271that complex to define a variant that provides namespaces:
272
273\starttyping
274\newcount\indirectmain \indirectmain=1
275\newcount\indirectuser \indirectuser=2
276
277\indirectluacall \indirectmain
278    {function 1}
279    {some string}
280\relax
281
282\indirectluacall \indirectuser
283    {function 1}
284    {some string}
285\relax
286\stoptyping
287
288A matching implementation is this:
289
290\starttyping
291lua.calls = lua.calls or { }
292
293local main = { }
294
295lua.calls[1] = function(name,...)
296    main[name](...)
297end
298
299main["function 1"] = function(a,b,c)
300    -- do something with a,b,c
301end
302
303local user = { }
304
305lua.calls[2] = function(name,...)
306    user[name](...)
307end
308
309user["function 1"] = function(a,b,c)
310    -- do something with a,b,c
311end
312\stoptyping
313
314Of course this is also ok:
315
316\starttyping
317\indirectluacall \indirectmain 1
318    {some string}
319\relax
320
321\indirectluacall \indirectuser 1
322    {some string}
323\relax
324\stoptyping
325
326with:
327
328\starttyping
329main[1] = function(a,b,c)
330    -- do something with a,b,c
331end
332
333user[1] = function(a,b,c)
334    -- do something with a,b,c
335end
336\stoptyping
337
338Normally a macro package, if it wants to expose this mechanism, will provide a
339more abstract interface that hides the implementation details. In that case the
340user is not supposed to touch \type {lua.calls} but this is not much different
341from the limitations in redefining primitives, so users can learn to live with
342this.
343
344\stopsection
345
346\startsection[title=Practice]
347
348There are some limitations. For instance in \CONTEXT\ we often pass tables and
349this is not implemented. Providing a special interface for that is possible but
350does not really help. Often the data passed that way is far from constant, so it
351can as well be parsed by \LUA\ itself, which is quite efficient. We did some
352experiments with the more simple calls and the outcome is somewhat disputable. If
353we replace some of the \quote {critital} calls we can gain some 3\% on a run of
354for instance the \type {fonts-mkiv.pdf} manual and a bit more on the command
355reference \type {cont-en.pdf}. The first manual uses lots of position tracking
356(an unfortunate side effect of using a specific feature that triggers continuous
357tracking) and low level font switches and many of these can benefit from the
358indirect call variant. The command reference manual uses \XML\ processing and
359that involves many calls to the \XML\ mapper and also does quite some string
360manipulations so again there is something to gain there.
361
362The following numbers are just an indication, as only a subset of \type
363{\directlua} calls has been replaced. The 166 page font manual processes in about
3649~seconds which is not bad given its complexity. The timings are on a Dell
365Precision M6700 with Core i7 3840QM, 16 GB memory, a fast SSD and 64 bit Windows
3668. The binaries were cross compiled mingw 32 bit by Luigi. \footnote {While
367testing with several function definitions we noticed that \type {math.random} in
368our binaries made jit twice as slow as normal, while for instance \type
369{math.sin} was 100 times faster. As the font manual uses the random function for
370rendering random punk examples it might have some negative impact. Our experience
371is that binaries compiled with the ms compiler are somewhat faster but as long as
372the engines that we test are compiled similarly the numbers can be compared.}
373
374% old: 8.870 8.907 9.089        / jit: 6.948 6.966 7.009         / jiton: 7.449 7.586 7.609
375% new: 8.710 8.764 8.682 | 8.64 / jit: 6.935 6.969 6.967  | 6.82 / jiton: 7.412 7.223 7.481
376%
377% 3% on total, 6% on lua
378
379\starttabulate[|lT|cT|cT|cT|]
380\HL
381\NC          \NC \LUATEX \NC \LUAJITTEX \NC \LUAJITTEX\ + jit \NC \NR
382\HL
383\NC direct   \NC 8.90     \NC 6.95      \NC 7.50              \NC \NR
384\NC indirect \NC 8.65     \NC 6.80      \NC 7.30              \NC \NR
385\HL
386\stoptabulate
387
388So, we can gain some 3\% on such a document and given that we spend probably half
389the time in \LUA, this means that these new features can make \LUA\ run more than
3905\% faster which is not that bad for a couple of lines of extra code. For regular
391documents we can forget about jit which confirms earlier experiments. The
392commands reference has these timings:
393
394\starttabulate[|lT|cT|cT|cT|]
395\HL
396\NC          \NC \LUATEX \NC \LUAJITTEX \NC \NR
397\HL
398\NC direct   \NC 2.55    \NC 1.90       \NC \NR
399\NC indirect \NC 2.40    \NC 1.80       \NC \NR
400\HL
401\stoptabulate
402
403Here the differences are larger which is due to the fact that we can indirect
404most of the calls used in this processing. The document is rather simple but as
405mentioned is encoded in \XML\ and the \TEX||\XML\ interface qualifies for this
406kind of speedups.
407
408As Luigi is still trying to figure out why jitting doesn't work out so well, we
409also did some tests with (in itself useless) calculations. After all we need
410proof. The first test was a loop with 100.000 step doing a regular \type
411{\directlua}:
412
413\starttyping
414\directlua {
415    local t = { }
416    for i=1,10000
417        do t[i] = math.sin(i/10000)
418    end
419}
420\stoptyping
421
422The second test is a bit optimized. When we use jit this kind of optimizations
423happens automatically for known (!) functions so there is not much won.
424
425\starttyping
426\directlua {
427    local sin = math.sin
428    local t = { }
429    for i=1,10000
430        do t[i] = sin(i/10000)
431    end
432}
433\stoptyping
434
435We also tested this with \type {\indirectlua} and therefore defined some
436functions to test the call variant:
437
438\starttyping
439lua.calls[1] = function()
440    -- overhead
441end
442
443lua.calls[2] = function()
444    local t = { }
445    for i=1,10000 do
446        t[i] = math.sin(i/10000) -- naive
447    end
448end
449
450lua.calls[3] = function()
451    local sin = math.sin
452    local t = { }
453    for i=1,10000 do
454        t[i] = sin(i/10000) -- normal
455    end
456end
457\stoptyping
458
459These are called with:
460
461\starttyping
462\indirectluacall0\relax
463\indirectluacall1\relax
464\indirectluacall2\relax
465\stoptyping
466
467The overhead variant demonstrated that there was hardly any: less than 0.1 second.
468
469\starttabulate[|lT|lT|cT|cT|cT|]
470\HL
471\NC                 \NC        \NC \LUATEX \NC \LUAJITTEX \NC \LUAJITTEX\ + jit \NC \NR
472\HL
473\NC directlua       \NC normal \NC 167     \NC 64         \NC 46                \NC \NR
474\NC                 \NC local  \NC 122     \NC 57         \NC 46                \NC \NR
475\NC indirectlua     \NC normal \NC 166     \NC 63         \NC 45                \NC \NR
476\NC                 \NC local  \NC 121     \NC 56         \NC 45                \NC \NR
477\NC indirectluacall \NC normal \NC 165     \NC 66         \NC 48                \NC \NR
478\NC                 \NC local  \NC 120     \NC 60         \NC 47                \NC \NR
479\HL
480\stoptabulate
481
482The results are somewhat disappoint but not that unexpected. We do see a speedup
483with \LUAJITTEX\ and in this case even jitting makes sense. However in a regular
484typesetting run jitting will never catch up with the costs it carries for the
485overall process. The indirect call is somewhat faster than the direct call.
486Possible reasons are that hashing at the \LUA\ end also costs time and the
487100.000 calls from \TEX\ to \LUA\ is not that big a burden. The indirect call is
488therefore also not much faster because it has some additional parsing overhead at
489the \TEX\ end. That one only speeds up when we pass arguments and even then not
490always the same amount. It is therefore mostly a convenience feature.
491
492We left one aspect out and that is garbage collection. It might be that in large
493runs less loading has a positive impact on collecting garbage. We also need to
494keep in mind that careful application can have some real impact. Take the
495following example of \CONTEXT\ code:
496
497\startntyping
498\dorecurse {1000} {
499
500    \startsection[title=section #1]
501
502        \startitemize[n,columns]
503            \startitem test \stopitem
504            \startitem test \stopitem
505            \startitem test \stopitem
506            \startitem test \stopitem
507        \stopitemize
508
509        \starttabulate[|l|p|]
510            \NC test \NC test \NC \NR
511            \NC test \NC test \NC \NR
512            \NC test \NC test \NC \NR
513        \stoptabulate
514
515        test {\setfontfeature{smallcaps} abc} test
516        test {\setfontfeature{smallcaps} abc} test
517        test {\setfontfeature{smallcaps} abc} test
518        test {\setfontfeature{smallcaps} abc} test
519        test {\setfontfeature{smallcaps} abc} test
520        test {\setfontfeature{smallcaps} abc} test
521
522        \framed[align={lohi,middle}]{test}
523
524        \startembeddedxtable
525            \startxrow \startxcell x \stopxcell \startxcell x \stopxcell \stopxrow
526            \startxrow \startxcell x \stopxcell \startxcell x \stopxcell \stopxrow
527            \startxrow \startxcell x \stopxcell \startxcell x \stopxcell \stopxrow
528            \startxrow \startxcell x \stopxcell \startxcell x \stopxcell \stopxrow
529            \startxrow \startxcell x \stopxcell \startxcell x \stopxcell \stopxrow
530        \stopembeddedxtable
531
532    \stopsection
533
534    \page
535
536}
537\stopntyping
538
539These macros happen to use mechanism that are candidates for indirectness.
540However, it doesn't happen often you you process thousands of pages with mostly
541tables and smallcaps (although tabular digits are a rather valid font feature in
542tables). For instance, in web services squeezing out a few tens of seconds might
543make sense if there is a large queue of documents.
544
545\starttabulate[|lT|cT|cT|cT|]
546\HL
547\NC          \NC \LUATEX \NC \LUAJITTEX \NC \LUAJITTEX\ + jit \NC \NR
548\HL
549\NC direct   \NC 19.1    \NC 15.9       \NC 15.8              \NC \NR
550\NC indirect \NC 18.0    \NC 15.2       \NC 15.0              \NC \NR
551\HL
552\stoptabulate
553
554Surprisingly, even jitting helps a bit here. Maybe it relates the the number of
555pages and the amount of calls but we didn't investigate this. By default jitting
556is off anyway. The impact of indirectness is more than in previous examples.
557
558For this test a file was loaded that redefines some core \CONTEXT\ code. This
559also has some overhead which means that numbers for the indirect case will be
560somewhat better if we decide to use these mechanisms in the core code. It is
561tempting to do that but it involves some work and it's always the question if a
562week of experimenting and coding will ever be compensated by less. After all, in
563this last test, a speed of 50 pages per second is not that bad a performance.
564
565When looking at these numbers, keep in mind that it is still not clear if we end
566up using this functionality, and when \CONTEXT\ will use it, it might be in a way
567that gives better or worse timings than mentioned above. For instance, storing \LUA\
568code in the format is possible, but these implementations force us to serialize
569the \type {lua.calls} mechanism and initialize them after format loading. For that
570reason alone, a more native solution is better.
571
572\stopsection
573
574\startsection[title=Exploration]
575
576In the early days of \LUATEX\ Taco and I discussed an approach similar do
577registers which means that there is some \type {\...def} command available. The
578biggest challenge there is to come up with a decent way to define the arguments.
579On the one hand, using a hash syntax is natural to \TEX, but using names is more
580natural to \LUA. So, when we picked up that thread, solutions like this came up
581in a Skype session with Taco:
582
583\starttyping
584\luadef\myfunction#1#2{ tex.print(arg[1]+arg[2]) }
585\stoptyping
586
587The \LUA\ snippet becomes a function with this body:
588
589\starttyping
590local arg = { #1, #2 } -- can be preallocated and reused
591-- the body as defined at the tex end
592tex.print(arg[1]+arg[2])
593\stoptyping
594
595Where \type {arg} is set each time. As we wrapped it in a function we can
596also put the arguments on the stack and use:
597
598\starttyping
599\luadef\myfunction#1#2{ tex.print((select(1,...))+(select(2,...)) }
600\stoptyping
601
602Given that we can make select work this way (either or not by additional
603wrapping). Anyway, both these solutions are ugly and so we need to look further.
604Also, the \type {arg} variant mandates building a table. So, a natural next
605iteration is:
606
607\starttyping
608\luadef\myfunction a b { tex.print(a+b) }
609\stoptyping
610
611Here it becomes already more natural:
612
613\starttyping
614local a = #1
615local b = #2
616-- the body as defined at the tex end
617tex.print(a+b)
618\stoptyping
619
620But, as we don't want to reload the body we need to push \type {#1} into the
621closure. This is a more static definition equivalent:
622
623\starttyping
624local a = select(1,...)
625local b = select(2,...)
626tex.print(a+b)
627\stoptyping
628
629Keep in mind that we are not talking of some template that gets filled in and
630loaded, but about precompiled functions! So, a \type {#1} is not really put there
631but somehow pushed into the closure (we know the stack offsets).
632
633Yet another issue is more direct alias. Say that we define a function at the
634\LUA\ end and want to access it using this kind of interface.
635
636\starttyping
637function foo(a,b)
638    tex.print(a+b)
639end
640\stoptyping
641
642Given that we have something:
643
644\starttyping
645\luadef \myfunctiona a b { tex.print(a+b) }
646\stoptyping
647
648We can consider:
649
650\starttyping
651\luaref \myfunctionb 2 {foo}
652\stoptyping
653
654The explicit number is debatable as it can be interesting to permit
655an arbitrary number of arguments here.
656
657\starttyping
658\myfunctiona{1}{2}
659\myfunctionb{1}{2}
660\stoptyping
661
662So, if we go for:
663
664\starttyping
665\luaref \myfunctionb {foo}
666\stoptyping
667
668we can use \type {\relax} as terminator:
669
670\starttyping
671\myfunctiona{1}{2}
672\myfunctionb{1}{2}\relax
673\stoptyping
674
675In fact, the call method discussed in a previous section can be used here as well
676as it permits less arguments as well as mixed types. Think of this:
677
678\starttyping
679\luadef \myfunctiona a b c { tex.print(a or 0 + b or 0 + c or 0) }
680\luaref \myfunctionb {foo}
681\stoptyping
682
683with
684
685\starttyping
686function foo(a,b,c)
687    tex.print(a or 0 + b or 0 + c or 0)
688end
689\stoptyping
690
691This could be all be valid:
692
693\starttyping
694\myfunctiona{1}{2}{3]\relax
695\myfunctiona{1}\relax
696\myfunctionb{1}{2}\relax
697\stoptyping
698
699or (as in practice we want numbers):
700
701\starttyping
702\myfunctiona 1 \scratchcounter 3\relax
703\myfunctiona 1 \relax
704\myfunctionb 1 2 \relax
705\stoptyping
706
707We basicaly get optional arguments for free, as long as we deal with it properly
708at the \LUA\ end. The only condition with the \type {\luadef} case is that there
709can be no more than the given number of arguments, because that's how the function
710body gets initialized set up. In practice this is quite okay.
711
712% After this exploration we can move on to the final implementation and see what we
713% ended up with.
714
715\stopsection
716
717% \startsection[title=The final implementation]
718%     {\em todo}
719% \stopsection
720
721\startsection[title=The follow up]
722
723We don't know what eventually will happen with \LUATEX. We might even (at least
724in \CONTEXT) stick to the current approach because there not much to gain in
725terms of speed, convenience and (most of all) beauty.
726
727{\em Note:} In \LUATEX\ 0.79 onward \type {\indirectlua} has been implemented as
728\type {\luafunction} and the \type {lua.calls} table is available as \type
729{lua.get_functions_table()}. A decent token parser has been discussed at the
730\CONTEXT\ 2013 conference and will show up in due time. In addition, so called
731\type {latelua} nodes support function assignments and \type {user} nodes support
732a field for \LUA\ values. Additional information can be associated with any nodes
733using the properties subsystem.
734
735\stopsection
736
737\stopchapter
738
739\stopcomponent
740