LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Subject: Re: Modules
From: Hans Aberg <[log in to unmask]>
Date: Tue, 30 Jun 1998 12:44:27 +0200
In-Reply-To: <[log in to unmask]>
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (42 lines)
At 10:01 +0100 98/06/30, David Carlisle wrote:
>> LaTeX already has several very slow commands with slow parsing, for
>> example the variations of "new" with the LaTeX special style of defining
>> arguments.
>Having a definition command that is slower than def is acceptable.
>Having a mechanism where the _use_ of commands is an order of magnitude
>(or more) slower than directly calling a control sequence is not
>acceptible, as long as the system is to be programmed in TeX (or a
>TeX-like system such as etex or omega).

  I am aware that optimization is more important the more often the command
is used. Pros use a profiler which tells which commands are used the most,
and one goes in and optimizes mainly those.

>I mention this point (again) not to try to stifle discussion but because
>I got rather lost at what level you are intending some of your module
>proposals to be used.

  Since modules are a generalization of the ideas used in L3PL, the idea is
that it should be used as an unifying concept on all levels (except in
cases where special low level optimization excludes it).

  So on a low level, you can use modules only as a naming convention, but
on the higher level it is possible to do more complicated things. It is
also possible to combine: The low level uses high level commands for the
first quick and dirty development, and then one goes in and optimizes where

  It is not necessary to use always the same way to call the module
command. In some environments using a slow parsing <...> style might be
just fine, but in other cases it might not: Perhaps it is too slow, perhaps
the syntax is unworkable.

  The details of this, what might work in different contexts, one finds out
by developing the modules concept in those different contexts.

  Hans Aberg
                  * Email: Hans Aberg <mailto:[log in to unmask]>
                  * Home Page: <>
                  * AMS member listing: <>