Volkan Yavuz writes: > A package author identifies not just the package name but also gives > it's location within a hierarchy (modules, submodule). This hierarchy > may also correspond to some extent to the directory structure on > CTAN.... :-) It may be feasible to use a deeper module hierarchy than > the current directory structure on CTAN to be able to categorize > packages more exactly. > > \ProvidesPackage{latex3/contrib/math} This is what I was hinting at when I referred to \base/ltbibl/@citex and \contrib/supported/splat/somethinguseful. (May I suggest not including `latex3', since it is superfluous, and we want upward compatibility with LaTeX4 . . . .) Some of us are talking at cross-purposes, so allow me to clarify what I was getting at before. There are some conflicting concerns: 1. Macro/symbol names should follow a consistent scheme, be easy to remember and use. Hence `long' names. 2. I was addressing the problem of keeping format file size and control sequence space requirements to a minimum. This has been one of the stated aims of the project. Hence `short' names. Is this no longer a concern? Is it OK if all macro names are thirty or more characters long? If so, dump the short names altogether, and stick with the long names. We use smart editors. Hans Aberg writes: > So a command like this could be useful to load all macros in > latex3/contrib/math, but it would not abbreviate the names. Instead an user > would define a special environment which abbreviates the names. Inventing > something: > \module{short}{latex3/contrib/math}{m} > and as long as the locality is valid, names \m/foo would expand to > \latex3/contrib/math/foo. > > One reason for doing it this way is that it is difficult know in advance > what kind of blends of modules users may make use of. > > Then one could of course think of more complicated things (like search > paths etc), but I think this would suffice quite far. My `gut' feeling is that this is a Very Bad Idea, but I'm not sure why. Perhaps because it doesn't lend itself to portable code. LaTeX `code' tends to be reused in much smaller chunks than is normal with other programming languages. If you copy some code from within some `module' construct, you have to be very careful where you put it. It might find itself being called inside some other `module', possibly with bizarre results. PS Nice photo! Javier Bezos writes: > Renaming commands > ~~~~~~~~~~~~~~~~~ > Suppose someone is determined to study the internal latex code with the > new naming scheme. He take the TeXbook and... surprise! The latex code is > absolutely unintelligible. This was my reaction too. And the new names are often not transparent renamings of the original - as you point out, some are subtly different. You need to know not only the new names but you need to keep the implementations in mind too. > I thing the primitive (and maybe plain) > command names should be preserved with perhaps some minute changes; eg. > \_box instead of \box (you may think of that as "no module"). Interesting idea. But I think we are looking at an `all-or-nothing' solution. I don't recall seeing LaTeX listed in those `shoot yourself in the foot' jokes; let's keep it that way. > However, I think it's not a good idea to change at all the meaning of > those well established names. If \box has another meaning it could > lead to confusion. A couple of days ago I needed a macro for typesetting program code within math mode. We have \mathrm, \mathtt, etc. so I thought: why not \mathcode? Oops, that's a TeX primitive. Ben L. User would probably be annoyed about that. I must admit that I'm slowly coming around to the [removeoldnames] option.