References: Your message of "Wed, 01 Jul 1998 12:21:33 +0200." 
            <v03110700b1bfbb8f93d9@[130.237.37.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <v03110701b1bfdd08714a@[130.237.37.138]>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  <E0yrKKi-0007WS-00@heaton.cl.cam.ac.uk>
Date:         Wed, 1 Jul 1998 14:52:52 +0200
From: Hans Aberg <haberg@MATEMATIK.SU.SE>
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

At 11:41 +0100 98/07/01, Robin Fairbairns wrote:
>people aren't (in principle) against the idea.  the argument is not
>_against_ multiple levels, but rather whether they can be made to work
>acceptably in a tex environment.

  Right. This is always the problem with TeX. I want to bring out these
ideas to see where they lead within the TeX capacity. The final result
shows when one attempts to program TeX, with its limited capacity.

>  *all* levels of a tex macro package are processed by the same
>interpreter.  that interpreter has several extraordinary properties
>which cause `crosstalk' between the levels (for example, expandability
>does just this).

  It is clear that one can never get around the way TeX is constructed.
However, it is possible to simulate structures in TeX, and that will
suffice.

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

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

  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.

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

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

  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. -- L3PL programming will probably need some other conventions, but
this might be an input.

  Hans Aberg
                  * Email: Hans Aberg <mailto:haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>