LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Richard Walker <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 22 Jun 1998 16:31:11 +1000
text/plain (86 lines)
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.