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]>
Date: Sat, 10 Jan 2009 02:10:14 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (54 lines)

 > I was reading l3precom, and was wondering what exactly it does.  I can't
 > really work it out (other than it seems to pre-date LaTeX2e, and I
 > wonder if it's that relevant).

at the moment it isn't relevant I guess as it doesn't have any application and
whether or not it will become relevant again, who knows. I agree it is
somewhat strange that this is within the svn while the original application it
was used for (called LDB) isn't.

A lot of the ideas that eventually became expl3 date back to full kernel
implementation in 93 or so. Back then we were experimenting with a
configuration concept where a designer could specify how objects behave in
dependence to their placement in a document tree, e.g. a subheading
immediately following a heading requires different spacing to the situation
that it is following normal text (or the end of a display, or ...)

In a very limited fashion even todays 2e has that capability (with stress on
"very" :-).

Now those relationships can become very complex and at the same time need to
be stored in a fashion that allows fast retrival within the document. As both
are conflicting requirements, the concenpt was to provide a declaritive
specification language that is internally compiled into some structure which
would be horrible to input directly but is fast to access. That transformation
took quite some time. So what we did was to build a fairly complex structure
(slowly) and dump the result in a way that it could be read in extremely fast
(kind of like the way the TeX format works, you do all the parsing and setup
once and then dump a memory image).

Now l3precom offers the low-level framework for doing something like this. The
LDB (LaTeX Data Base) of which we actually produced two conceptally very
different implementations, made use of \cs_gen_sym:N to build up a huge graph
to traverse when figuring out which specification to apply in a specific
situation in a document. Building that graph was done in a class (once) which
then wrote out all the pointer definitions into an external file. Later calls
to the class would then simply load the stored graph.

That's roughly the history. Now why isn't there any LDB? partly because we
couldn't find a final good presentational syntax on the designer level that we
felt was understandable to a "designer" and not just to a programmer. So we
put the whole idea on the shelf. I still think it has some merrits though, and
might take it out of the cupboard one day.

My memory may play tricks on me but I think we decided to keep l3precom on the
active tree as there may be a situation where you want to do some extensive
work/calculation and then dump the resulting definitions in precompiled form
for fast loading. If this is going to be useful one day is in the stars.