Message-ID:  <E0yrKKi-0007WS-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 12:21:33 +0200." 
              <v03110700b1bfbb8f93d9@[130.237.37.151]>
Date:         Wed, 1 Jul 1998 11:41:47 +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 wonder why people are so against building several development levels,
> because this is the normal way computer programming is structured otherwise:

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.

>   The lowest level is the assembler which expands to simple machine
> instructions. On top of that, one might build a language like C, which does
> not impose runtime checks and itself is compiled, not interpreted. Then on
> top of that, one might build a more advanced language with runtime checks,
> and often C is a language to use for writing that language. Finally this
> more advanced language can be used to build user applications.
>
>   Similarly, in TeX the assembler might correspond to the most lowlevel
> macros. It would be great if one could add some kind of C compiler on top
> of that, which does not add much runtime overhead. The more advanced
> language might correspond to LaTeX itself, which is used by the user and by
> adding high level structures.

this is all very well: it has a nice feel to it.  but tex isn't like
that.  *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).

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.

>   I gather L3PL is intended to correspond to this lowest assembler level,
> but I think it would help if one could add a C-level, that is, if it does
> not add much overhead.

since you originally talked (some time before the present thread)
about modular naming, i've been thinking about it, on and off.  at one
stage i was intending to present a paper about the issue at eurotex,
but have now timed out on a paper at tug'98, even.  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.

robin