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

[Will Robertson]

On 08/03/2009, at 11:57 PM, Jonathan Fine wrote:

> Will Robertson wrote:
>
>>> It would help if the LaTeX3 project adopted a programming  
>>> environment that could produce macros for both the secure and  
>>> traditional environments.
>> The current expl3 is set up to provide this already. There is an  
>> option when l3names is processed to remove all of the old TeX  
>> primitives from the user namespace; this automatically makes any  
>> documents processed "secure", since users can't change catcodes and  
>> the only commands provided to them are "document-level" macros.
>
> 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?  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? 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.

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

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.

Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2415 bytes
Desc: not available
Url : http://tug.org/pipermail/summer-of-code/attachments/20090309/f4f2eef2/attachment.bin