binding for etoolbox

[kohlhase]

I find myself using the etoolbox package more and more. It provides nice programming primitives for LaTeX. And at the same time, I like supporting LaTeXML by just RawTeXing parts of the LaTeX packges (at least for roughing things out). Currently, that means that I cannot use etoolbox primitives.

I must confess that I have not tried just inputting etoolbox.sty and letting LaTeXML figure things out, but I think that in the end this will not be efficient.

Therefore, ... a binding would be nice to have.

[kohlhase]

@dginev this might also be interesting for you to look at.

[dginev]

One interesting bit is the observation that code interpreted through RawTeX is even less efficient than LaTeXML's bindings.

I was brainstorming with Bruce about a radical optimization strategy that would refactor central chunks of bottleneck functionality into pure C and interface it via Perl's XS wrappers.

Interpreting raw TeX directly sounds like a good self-contained target for such a refactoring. Of course that might mean that we turn the entire Gullet and Stomach into C code, and possibly throw in the Token(s) and Definition classes in there for good measure. (Wildly hand-waving here)

If we can optimize the raw interpretation of TeX definitions we may get magnitudes of speedup in the cases of Tikz and XY, where we are dealing with tens or hundreds of thousands expansions per document.

As to the specific etoolbox.sty, it's hopefully just a regular binding-writing exercise.

[brucemiller]

How do you see that RawTeX is less efficient? At least for macros, it should end up pretty much the same.

[kohlhase]

For the stuff in etoolbox, which is new conditionals, iterators, ... there are perl primitives, and that should be more efficient than loads of \expandafter and \ifx.

[dginev]

Exactly - less efficient in the sense that you need to expand 100 macros to do the TeX equivalent of what would be one or two native Perl commands (e.g. the pseudo random number generation in Tikz)

[brucemiller]

Ah, ok, i misunderstood; certainly handwritten Perl should be more efficient

[brucemiller]

For grins, it would be interesting to know if it can process the file as-is.
But it sounds like it would still be useful to develop a binding for.... (after 0.8)

[dginev]

As an answer:

Testing invocation:

latexmlc --preload=/usr/local/texlive/2013/texmf-dist/tex/latex/etoolbox/etoolbox.sty 'literal:a' --whatsin=fragment

Final report (lots of errors omitted):

1 warning; 19 errors; 1 fatal error; 16 undefined macros[\etb@renew@command, \ifboolexpr,
 \insc@unt, \ifcsstring, \notblank, \etb@provide@command, \ifstrequal, \@argdef, \renewrobustcmd, 
\providerobustcmd, \etb@boolexpr, \ifcsltxprotect, \ifdefstrequal, \ifdefstring, \ifdefltxprotect, \csshow]
 at /home/dreamweaver/perl5/lib/perl5/LaTeXML/Common/Error.pm line 67, <$IN> line 661.

Not quite there yet it seems.

[kohlhase]

note that etoolbox.sty depends on etex.sty that may be independently interesting for LaTeXML (though it looks quite nastily low-level).

[kohlhase]

Maybe etoolbox.sty.ltxml would be something for Kim/Lukas over the summer?

[brucemiller]

Indeed; feel free to bring that up with them...or i will. In addition to continuing or finishing the Doc/OOffice stuff. Which reminds me: Since they've got some expertise with XSLT now, it might be nice to knock off a transform to Wiki markdown?

[kohlhase]

Lukas knows XSLT and Kim has some experience with LaTeXML bindings, so that looks like a good division of labor. You should bring this up with them, I am just advising you.