[tug-summer-of-code] Project idea: LaTeX3 "microkernel"

Jonathan Fine jfine at pytex.org
Sun Mar 8 15:24:03 CET 2009


Hello Will

You wrote:
>> 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 
conventions.

> 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. 

That's good.

> But 
> 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.

-- 
Jonathan


More information about the summer-of-code mailing list