At 23:41 +0200 98/07/01, Frank Mittelbach wrote:
>beside "my please stop mail" i do want to explain why i think that a
>module/submodule concept as suggested by Hans is doomed to failure if
>applied all levels of programming within TeX.
>essentially i said this already in my mail a few days ago but perhaps
>it was not clear enough to people not having written large scale
The reason I continued was that I got the impression that Frank
Mittelbach misunderstood the whole idea of modules. :-)
>Richard suggested at some point a syntax like \foo/bar_baz:nn and said
>"with catcode 11 for / _ :" now that is beside syntactic sugar exactly
>what we have now (where the statement is: the module name is the first
>word up to an _)
>it may be that this is better to read (although i doubt) it but it is
>not functionally offering anything new. and importantly it doesn't
>offer what Hans has in mind (even though in some side remarks it
>sounds as if he thinks one can combine the two)
>one of the main arguments for submodules (or class structures in OO
>languages) is the ability to overload functions/procedures
Not really. So called name overloading does not have anything to do with
avoiding name clashes, or developing in structured units like modules. Name
overloading is just another feature that sometimes is convenient. Object
orientation (OO) is often tied to the concept of derived classes, which in
its turn is often tied to data with the ability to change class derivation
dynamically at runtime, and it is not clear to me what that would mean to
TeX, even though it is an interesting question.
The main idea with modules, the way I see it, apart from avoiding name
clashes, is allowing the developer to develop in logical units without
having to bother about the internals of other modules, only their
interface. (So the question of writing out the names directly or by some
parsing mechanism is a question of giving the module a different interface.)
The question is how much of this that can be made in TeX, but this is
>and here is where it stops being usable. if the concept allows for
>this than at runtime! the binding has to be changed and that means:
>any expansion text of any macros can't contain something like
>\foo/bar_baz:nn as above (ie a token) but it must contain things that
>live on the module/submodule level ie is looked up by some internally
>programmed module handling interface. and that will bring you to my
>exponential growth in slowness.
I think the whole misunderstanding by Frank Mittelbach is that he thinks
that just because the modules concept admits a certain feature it also
requires it. Name overloading in TeX, which is already present to some
extent in LaTeX on the high level by the use of optional commands, would be
great, but it is clear that TeX has a very limited capacity of achieving
that and that it is slow. But then simply do not use that in situations
Summing it up, the use of names \foo_bar_baz:nn and viewing them as a
part of a group named "foo" is already in some sense a module, where the
use of "_" confuses the two concept of a module separator and a word
> as i said several times: *prove* me wrong by giving me something
>that i can run through initex which works, ie compiles at least simple
>documents without needing a minute per page --- don't try to prove me
>wrong by using applying gut-feeling from experiences in languages like
>C++, Smalltalk, Java, Modula, you name it. We have heard these
>arguments by now and we agree about their usefulness but we claim
>(from our experience) that they can't and shouldn't be applied to that
>level in TeX.
Some other good languages one easily gets tired of are LISP, Scheme, SML,
and Haskell, not to mention Perl, Simula, Pascal and all those database
It is clear that anything in the TeX domain must be on the conditions of
TeX. But it is possible to state objectives one wants to achieve with those
languages, and make them useful within TeX. For example:
1. Avoiding name clashes.
2. Avoiding being burdened with remembering names.
3. Ability to develop in logical units, only having to worry about the
interface with other logical units.
4. Producing dynamic, runtime data.
5. Ability to reuse code in another context.
6. For new logical structures, preferably only having to write code for
what differs relative already written code.
(Roughly a translation of the concepts: 1. name-spaces/classes; 2. name
overloading; 3. name-spaces/classes, 4. runtime derived OO classes; 5. code
encapsulated in classes; 6. class derivation.)
Those objectives make sense, even though it can be hard to figure out how
to do it in TeX.
* Email: Hans Aberg <mailto:[log in to unmask]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>