[tug-summer-of-code] Project idea: LaTeX3 "microkernel"
jfine at pytex.org
Sun Mar 8 15:24:03 CET 2009
>> Yes, I already knew about this option. But neither the traditional
>> nor the secure environments use \cs_set_eq:NN as the name for \let,
>> which is what follows from your suggestion.
> Huh? I might have completely misunderstood you. Isn't the "secure"
> variant of Plain a specially written variant of Plain that prevents
> users from using \def, \let, \catcode, and so on?
Yes. And it stores these primitives in \_def, \_let, \_catcode etc.
> What's that got to do
> with the name of \cs_set_eq:NN besides the fact that it's no longer in
> the user namespace?
Nothing, except that it uses \_def, \_let etc. And LaTeX2e uses \def,
\let, etc. Sorry, but I'm not yet willing to adopt the expl3 naming
> The kernel early on uses \cs_set_eq:NwN as the
> literal primitive \let, but later defines a wrapper around it called
> \cs_set_eq:NN which is used in most of the other expl3 modules.
Thank you for this. I was not previously aware of this detail.
>> I am reluctant to 'fork' LaTeX. I'd much rather work with the LaTeX3
>> project to produce a secure variant of the relevant style and core
>> files. Are you up for that?
> In the long run, yes, I think we're talking on the same wavelength.
> if you want to support LaTeX in MathTran in the near future then LaTeX3
> isn't the place to look (since backwards compatibility is only a long
> term goal).
If I create a secure subset of LaTeX that's incompatible with a
subsequently produced LaTeX3 then they'll be a cost to pay. Either the
incompatibility remains (the users pay the cost) or we remove it (the
developers pay the cost).
> However, I do hope that the eventual design of (some of) the
> LaTeX document classes or document types allow a secure mode that would
> facilitate the type of processing the MathTran does.
Yes, I very much hope that also. And sooner rather than later. Hence
my contributions to this thread.
> Regarding forking LaTeX: I would encourage you to do so if the manpower
> is available for MathTran; the core and packages you would support are
> obviously very stable, and if you rename the resulting format then
> there's no licensing problem at all.
Thank you for this. However, I am still reluctant. MathTran resources,
like those for LaTeX3, are limited.
More information about the summer-of-code