LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Richard Walker <[log in to unmask]>
Thu, 18 Jun 1998 15:46:02 +1000
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (83 lines)
Well . . . Hans's ideas sent me scurrying back to The TeXbook (always
a good thing) to study the fine print about <parameter text>s.

Hans has come up with a useful hierarchical namespace system for

All I can say is . . . `cool!'.

I was a little concerned about ambiguities in L3PL caused by using _
to separate components, and then allowing _ within components.  I
think it is good to allow _ within a component (and @ for internals?!)
and then use something else (such as /) to separate the components.
This will be useful for external indexing programs (e.g. Emacs etags)
or even doc.sty.

Now bear with me for a few moments of madness.  Come to think of it,
what follows isn't much weirder^H^H^H^H^H^H^Hmore unusual than some of
the details of L3PL.  Even if you don't like the particulars, maybe
they might trigger a better idea or a totally different application?

OK, so now the base's internal macros look like this:


and if I write a package called `splat' my internal macros will
look like this:


The result: massive fmt file and control sequence bloat.  We need some
shortcuts.  Here are some possibilities.

1.  Use a variant of the Apple solution:  author/product
codes.  E.g. assign a four-(hex-)digit code to a developer.  Assume I
am allocated a5d4; then my macros begin \a5d4/. . .
There might be special codes for e.g. the LaTeX base and packages.
2.  Extend doc.sty to do the following:
(a)  The package writer uses the long names as above when editing the
dtx file.  We assume that the writer has the help of a good text
editor to save on keystrokes!
(b)  When run through TeX to extract the .cls/.sty/whatever file, the
long names of internal macros are rewritten in a canonical,
unique-across-all-packages short form, perhaps based on point 1 above.
(This must also be the same across TeX implementations.)  The package
writer might make the renaming explicit or give `hints'; there might
be a (more or less) sensible default.
(c)  Write out a .cut file (for `short cut') which specifies the
correspondence between long and short forms.  This file could also
include macro documentation, error messages, etc.  Something like
Emacs documentation strings?  (Write it out in a format that can be
loaded by AUC TeX?) Zillions of possibilities.  Maybe .cut is the
wrong suffix . . . .

People who only use the package don't need to worry about any of this;
the `exported' macros have `nice' names.

People who want to build on the package can `load' the .cut file in a
`special' way which sets up correspondences between long and short
names.  <- This needs some work to get it right; when you redefine an
internal macro you have to redefine both long and short names.  Once
you are done messing with the internals you can `undo' the
correspondences to free up the control sequence space.

Error messages relating to internal macros go via the .cut file so
that the user sees something `sensible', i.e. using the long names.
3.  Similar to point 2 above, but doc.sty writes out two separate
.cls/.sty/whatever files, one using the short names and one using the
long names.  Load whichever you need.  You still need the .cut file.
4.  As for 3, but write just one file; you specify what you want when
you load the file via a [shortnames] or [longnames] option.
(Hmm . . . not so good when used as \documentclass[longnames]{blah};
this filters down to later \usepackages unless you override it.)
You still need the .cut file.

What do you think?