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:[log in to unmask]> * Home Page: <http://www.matematik.su.se/~haberg/> * AMS member listing: <http://www.ams.org/cml/>