Message-ID:  <E0yrPIm-0000XN-00@heaton.cl.cam.ac.uk>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  Your message of "Wed, 01 Jul 1998 14:52:52 +0200." 
              <v03110701b1bfdd08714a@[130.237.37.138]>
Date:         Wed, 1 Jul 1998 17:00:07 +0100
From: Robin Fairbairns <Robin.Fairbairns@CL.CAM.AC.UK>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Optimizing LaTeX
Status: R

i wrote:

> >and of course, what's appropriate for an interpreter isn't necessarily
> >equally sensible for a compiled language.  we simply cannot hope to
> >compile tex without a major effort *outside* tex: an optimising
> >compiler written in tex is surely a nono -- one couldn't possibly
> >afford a pass of something (presumably) even slower than docstrip on
> >documents, and class and package files aren't really the problematic
> >issue as far as optimisation goes.

and hans aberg responded:

>   To give the optimizer another name than docstrip then, so it may be used
> at will.

the name of the program doesn't affect its speed at all (though i
suppose if you painted go-faster stripes down the side...)

the essence of my remark was that any useful optimiser is either
ridiculously difficult to write (on a par with tex itself, since it
has to parse tex input) or desperately slow.

>   The thing is that I wonder if it is so difficult to provide a compiler
> within TeX. Let's focus on \newcommand{\foo}[5]{def}; then LaTeX already
> expands this to a \define\foo#1#2#3#4#5{def} kind of definition. So one
> needs a way to write this expansion down in a file as a command.

*why* do we need this?  executing the \newcommand does indeed
ultimately lead to execution of a \def statement, as you suppose.  and
the \newcommand is slightly slower to execute than is the \def on its
own, but so what?  that command is only going to be executed once in a
tex run, after which the (tokenised) command definition is hashed away
somewhere and is executed as fast as one can hope.

>   I merely play around with this idea, to see where it leads.

as you may guess, i don't think it leads anywhere terribly useful.

i don't think an optimiser that operates on classes and packages helps
much, and i don't believe an optimiser that works on documents is
feasible.

> >..i've done a fair
> >bit of research since into naming systems (it's a topic that has
> >direct relevance to my research group), and i think i know how i would
> >structure a naming system within tex.  what i _don't_ know (after
> >several months of thinking about it) is how to implement such a
> >system.
>
>   With modules, I think if it should ever become more than a naming system,
> it is rather abstract as concept and hard to focus without a great deal of
> practical programming experience, and just thinking about it will not
> resolve that issue. I did some limited programming with the idea of
> modules, and I merely try to indicate some of the deeper aspects that I
> found suitable. But for developing the concepts of modules a great deal of
> more programming experience with the concept is needed, giving it a context.

it seems you're saying "we need to program these things before we've
got a coherent idea of how to name them".  this way (to my mind) leads
to madness, which was why i was re-reading the standard texts on naming.

>   By the way, I put up a doc, "modules/ModuleConventions.txt", on my home
> page, with contains some of the ideas I had that might be used to define
> modules.

you quote two home pages, but afaict this file isn't in either of them
(i tried conventional html suffixes too).

robin