Hi, I saw you are implementing new primitives such as appending to token list. This is interesting idea and I wander could you implement more new useful primitives like \appenddef, \prependdef where it would add something at begin or at the end of macro. And where you should not care about commands arguments. There is etoolbox with similar commands like \appto, \preto, \apptocmd,... I think primitves would be much more faster and trustworthy. Sometimes I get problems with \apptocmd when using it in tex4ht and trying to append to command with semicolon and it doesn't appends macros. Thanks in advance, Linas Stonys
On 5/4/2016 10:29 PM, linuxss Stonys wrote:
Hi, I saw you are implementing new primitives such as appending to token list. This is interesting idea and I wander could you implement more new useful primitives like \appenddef, \prependdef where it would add something at begin or at the end of macro. And where you should not care about commands arguments. There is etoolbox with similar commands like
i guess most macro packages implement appending and prepending stuff
\appto, \preto, \apptocmd,... I think primitves would be much more faster and trustworthy.
we have no plans for more primitives because there would be no end to it (every macro package has its own demands anyway) appending and prepending to token lists makes sense because they are registers and can be considered kind of containers concerning performance: there is less gain than one thinks as texs core operations are pretty well optimized (only on extremely large token lists one can measure a gain) and speed of tex is determined by many more factors (measuring some single aspect hardly makes sense) an dfor instance a few bad styling options (inefficient font switches and so) have more impact than a bit macro expansion concerning trustworthy: given the macro language and expansion one needs to know a bit what could happen and primitives don't make that any better
Sometimes I get problems with \apptocmd when using it in tex4ht and trying to append to command with semicolon and it doesn't appends macros.
that's a matter of programming (and again very dependant of what goes in such a macro call) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi,
On 05 May 2016, at 12:26, Hans Hagen
wrote: \appto, \preto, \apptocmd,... I think primitves would be much more faster and trustworthy.
Like Hans said: I think speed improvements are just wishful thinking. It is hard to beat the TeX language speed significantly from compiled C code if you are still doing more or less the same stuff the TeX language code would do. In (lua)TeX, useful speedups tend to come from doing a task differently, not from switching languages. Still planned for luatex is access to the macro replacement text as well as macro definition and possibly even alteration from the lua side of things. Altering macros from lua by using the lua token list interface would allow one to take macro parameters into account, and that would open up extra possibilities for sure. And it could improve reliability of such alterations, I assume. After some thinking, that sounds like a better way to go. In fact, thinking it over, I wonder whether we should not change \[e]toksapp and \[e]tokspre back to lua function calls? Best wishes, Taco
On 5/6/2016 11:01 AM, Taco Hoekwater wrote:
Hi,
On 05 May 2016, at 12:26, Hans Hagen
wrote: \appto, \preto, \apptocmd,... I think primitves would be much more faster and trustworthy.
Like Hans said: I think speed improvements are just wishful thinking. It is hard to beat the TeX language speed significantly from compiled C code if you are still doing more or less the same stuff the TeX language code would do. In (lua)TeX, useful speedups tend to come from doing a task differently, not from switching languages.
Still planned for luatex is access to the macro replacement text as well as macro definition and possibly even alteration from the lua side of things. Altering macros from lua by using the lua token list interface would allow one to take macro parameters into account, and that would open up extra possibilities for sure. And it could improve reliability of such alterations, I assume. After some thinking, that sounds like a better way to go.
apart from pitfalls due to reference counting and grouping but we can assume that only fearless users will use it -)
In fact, thinking it over, I wonder whether we should not change \[e]toksapp and \[e]tokspre back to lua function calls?
(that would demands more juggling and have no advantage i.e. be slower so probably not be used over the \expandafter{\the\foo... alternative} well, we had similar discussions about more primitives, as in fact quite some can be refitted to such calls; but that is all more a luatex 2+ issue than a version 1 issue as we have to draw the line somewhere Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen
-
linuxss Stonys
-
Taco Hoekwater