Reply-to: Mailing list for the LaTeX3 project <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
Message-id: <199506290811.EAA144622@acs3.bu.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date: Thu, 29 Jun 1995 04:11:39 -0500
From: Matthew Swift <swift@ACS.BU.EDU>
Sender: Mailing list for the LaTeX3 project <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
Subject: back to distribution conditions
Status: R

Back to distribution conditions.
 
I agree with Richard Stallman that LaTeX developers must address
the need to accomodate the easy use and distribution of
non-official substitutes for the features provided in the
official disk files containing LaTeX code.
 
I think a good solution would be a layer of abstraction between
the features that LaTeX code calls for and the disk files that
are loaded to provide the features.
 
In general, LaTeX relies too heavily on disk files to effect
abstraction that can be achieved other ways.  In this case, we
see that disk file names are being required to serve as 1) a
unique label for official segments of code.  Unique labels of
some kind are necessary to effectively establish a standard code
distribution.  These labels, I maintain, ought to be different
from 2) the unique labels by which a LaTeX _feature_ is known and
called for by code segments and possibly source documents.
 
Without this separation the system is not modular and I believe
there can be no satisfactory way to achieve the goal of an
effective standard that accommodates local variation.  If a
tweaked version of the official foo.sty is named foo.sty, then
the system standard is in danger, since disk file names in the
context of distributions and copyrights are presumed to uniquely
identify the file's contents.  If on the other hand the tweaked
version is called tweak-foo.sty, then the system flexibility is
in danger, since all references to foo.sty in an indefinite
number of files must be manually changed.
 
A consequence of the separation is that \documentclass{article}
would not refer to a disk file but to a document class.  If this
seems objectionable, I say it is because the implementation has
been mistaken for the concept.  If I am not mistaken, that error
is prohibited by the commandment about bowing down to false
idols, and by wisdom in other respectable books.  I think that no
part of a source document, not even the preamble. should be tied
rigidly to fixed code.  I think this is a matter of the basic
principle of data abstraction; I am arguing there should be a
layer between disk file and document description; the
justification is that it solves the problem of achieving an
easily extensible standard.  Everyone agrees in a LaTeX context
that "descriptive markup" is preferable to "visual markup"; I see
the situation as parallel.
 
It makes sense that the names (for purposes 1) and 2)) should
coincide in the official, default case.  But since disk file
names are limited by Microsoft DOS to 8+3 one-case format, I
think this should be a loose convention.
 
I can think of almost a dozen ways to implement this separation,
some more radical than others.  One ad hoc way which could be
implemented in a few minutes on top of any standard Unix TeX
distribution is to alias "latex" to include a preprocessing pass
(m4, sed, awk, perl, whatever) that would consult a two-column
table in an auxiliary file:
 
  # feature disk file (this line a comment) foo tweak-foo.sty
 
A similar database of exceptions could easily be obeyed by the
kpathsea search library.
 
All substitutions might be canceled by specifying a "strict" or
"official" option in one of numerous places (command line,
package option, class option, independent command).  Conversely,
and even more strictly, substitutions might be permitted only on
the explicit request of a "non-strict" or "permit-unofficial"
option.  These options could be implemented in one of various
ways, and (like the substitutions themselves) not necessarily
require a change to TeX or LaTeX.
 
Other large program suites such as GNU Emacs have implemented the
separation of feature from disk file in interesting and
successful ways.
 
The official LaTeX developers would never need to worry about the
compatibility of foo.sty with tweak-foo.sty, or the portability
of documents constructed with the substitution of tweak-foo.sty
for foo.sty: that is the responsibility of the author of
tweak-foo.sty, which the user uses at their own risk.
 
(PS Isn't this an idea like a virtual font?  I'm not sure about
fonts.)