[tug-summer-of-code] Project idea: LaTeX3 "microkernel"
wspr81 at gmail.com
Sun Mar 8 14:58:49 CET 2009
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2415 bytes
Desc: not available
Url : http://tug.org/pipermail/summer-of-code/attachments/20090309/f4f2eef2/attachment.bin
More information about the summer-of-code