Print

Print


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
macros.

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:

\base/ltbibl/@citex

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

\contrib/supported/splat/somethinguseful

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?

Richard.