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]>
Subject: Modules
From: Volkan Yavuz <[log in to unmask]>
Date: Sat, 20 Jun 1998 21:00:17 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (125 lines)
These are my thoughts regarding modules and a hierarchical
namespace. They are similar to what Hans has written, but slightly

* Specifying the Local Scope

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.


after this declaration, all macros that are \newcommand'ed within this
package are auto-magically[1] prefixed with something like

        [1] This would save package authors a lot of typing and
        automatically ensures that all macros have the correct

* Accessing Macros

When the author of that particular package wants to access macros
defined in some other package, he says


or for document authors respectively


   This could lead to the following: whenever a macro is requested, it
is searched along some kind of search path, i.e. it is first looked up
in "latex3/contrib/math", "latex3/base/toc" and finally
"latex3/base/ifthen".[2] It could well be looked up in some standard
system namespaces, too, or maybe it is not searched anywhere else.

        [2] This would save document authors a lot of typing since
        they needn't specify the fully qualified macro name. Because
        of \usepackage, LaTeX knows where to look for the macros.

   This only works as long as there is no name clash among the macros
in "latex3/contrib/math" and the public[3] macros in "latex3/base/toc"
and "latex3/base/ifthen". When a name is ambiguous, the macro has to
be fully qualified, e.g. something like "\latex3/base/ifthen/newif".

        [3] How about declaring macros public or private to some
        module. When declared private, they are not looked up
        automatically when not in the local scope. The local scope is
        determined by "\ProvidesPackage{the/local/scope}".

* Local Namespaces

It may be very useful to locally specify some valid namespaces which
are to be prepended to all unqualified macros. This could also be used
to rearrange the order in which the namespace is traversed in search
for a macro.

                % use macros from tabularx and graphics
                % no need to fully qualify their names
                % first look in tabularx, then in graphics

* Redefining Macro Names

In case there are macros with identical names from different
packages, it may be useful to allow redefinition of one of them to
disambiguate their names, so there is no need to fully qualify their
names. Say there is a macro "\phi" both in "latex3/contrib/math/phi"
and in "latex3/contrib/phys/phi". Both \phis are somewhat different
and needed throughout the document.


   After this, \phi from latex3/contrib/math is accessible "from
outside" as \mphi. Of course, this could equally well be achieved by
just writing a macro \mphi that expands to the fully qualified name of
\phi. There was some other reason to providing this functionality
which has just escaped my mind...


By specifying a local scope and using a search path, there should be
no problem for both package and document authors dealing with the now
somewhat long macro names as Richard has pointed out. I haven't
considered the impact on TeX's memory and performance, though.

The module name could also be used to distinguish officially released
packages which are available from CTAN from locally written packages,
which are either not meant to be published or are still in
development. How about reserving the prefix "latex3" for packages
which are released on CTAN and using something like
"edu/st-anford/drofnats" for packages written by an individual at
St-Anford? You see the obvious similarities to the way Java(tm)
handles packages which belong to the standard distribution and which
are developed elsewhere.

Regarding the similarity of the module/submodule names and the
directory structure on CTAN, how about making LaTeX Internet
aware. Lets let it load packages on-demand from the nearest CTAN
host... ;-)

Kind regards, Volkan

__volkan yavuz___________________________
mailto:[log in to unmask]
__________"May the source be with you!"__