David Carlisle writes: > 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. Speaking only for myself . . . Hmm . . . well, _I_ was talking about the names of `internal' macros. I wrote: > So instead of e.g. \chk_var_or_const:N we have \chk/var_or_const:N. Again: / _ : all have catcode 11. At this point I diverged from Hans a little . . . I like the <.../...> idea for the user but agree it is too inefficient (the implementation of LaTeX's environments notwithstanding). Going back to my earlier crazy ideas about short/long names I think that a package will generally use `long' names for its internals, and to refer to the internals of the base and other packages. Subject to my earlier reservations, Hans's `environments' can then be used, but I propose that they work differently. If a package splat wants to `export' a macro it must say e.g. \ProvidesPackage{splat} . . . \ExportCommand{my_macro:N}{mymacro} where \splat/my_macro:N is the internal `long' name and \mymacro is the exported name. \ExportCommand `keeps' a list of the correspondences for each package. If _in your document_ you want to `import' the short names you might say: \UseShortNames{splat} . . . \mymacro . . . Or if you only want the short names for a little while: \begin{shortnames}{splat} . . . \mymacro . . . \end{shortnames}. Both do \let\mymacro=\splat/my_macro:N. (I imagine that a part of \ExportCommand's work is to generate/update a macro \splat/do_import: (say) whose expansion is just that.) The only place you need to use \csname . . . \endcsname in this scheme is in the implementation of \ExportCommand. Comments? Richard.