Message-Id: <199402101205.AA18275@mail.cs.tu-berlin.de>
Reply-To: Mailing list for the LaTeX3 project <LATEX-L@DHDURZ1.BITNET>
Date:         Thu, 10 Feb 1994 11:07:43 CST
From: Alex Stark <jas1@eng.cam.ac.uk>
Sender: Mailing list for the LaTeX3 project <LATEX-L@DHDURZ1.BITNET>
To: Multiple recipients of list LATEX-L <LATEX-L@DHDURZ1.BITNET>
Subject:      Re: keyed options lists (Was: RE: A philosophical....)
Status: R

In Message Thu, 10 Feb 1994 20:47:03 +1100,
  "Kristoffer H. Rose" <kris@DIKU.DK> writes:

>
>Frank Poppe writes:
>
> > I suggested a way out of this as reaction to the "new features"

>
>        \section{full}
>        \section[mark=short]{full}
>        \section[mark=short, toc={longer, may contain =}]{full}
>
>*always* giving all options used, and allow
>
>        \section[short]{full}
>
>as a default for backwards compatibility and/or convenience.
>
>--
>Kristoffer Hxgsbro ROSE                         Internet: kris@diku.dk


I personally like the
   \section[mark=short, ...]{full}
syntax. Apart from anything else, as commands include increasing number of
options the assignment format should make them less confusing.


MP> I only quote this to point out that I am not alone in not understanding the
MP> distinction between option, package and class. Why this obfuscation?
MP>
MP> Anyway, the list environment is presumably a package to do lists, the output
MP> routine is a package to do output, so everything is up for grabs:-)
MP>
MP> However, I do agree that the \RequiresPackage command is *extremely*
MP> important if you take this attitude, equivalent to Modula-2's IMPORT
MP> statement. Are we also to be treated to DEFINITION and IMPLEMENTATION
MP> modules in LaTeX-3?:->


Is the idea of forcing a split between definition and implementation
necessarily a bad one? One of the key objectives of LaTeX 3 is surely to
make style (etc) design easier. Conflicts arising out of interactions
between different styles is a central problem. Surely the lesson to be
learnt from so much development of computer languages is that you have to
force users to conform to a structure that requires extra short-term effort.

The other apsect of computer language design that comes to mind is that the
implementation of the data storage must be hidden from the module user. If
we had an object-oriented system, I don't think that the variable `email'
would be available to be set elsewhere. This presents a fundamental problem:
if a letterhead design is customized problems may arise later if the
original module is changed.

Therefore some kind of explicit declaration of options is necessary. The
Latex3 team must make their own decisions about this. IMHO the package
users should, effectively be prevented from using any internal information
about their packages.

Alex Stark.
----------------------------------------------------------------------
J. Alex Stark          Signal Processing and Communications Laboratory
                                             Department of Engineering
email: jas1@uk.ac.cam.eng                      University of Cambridge
Tel:   [+44]223 3 32767                             Trumpington Street
Fax:   [+44]223 3 32662                         Cambridge, CB2 1PZ, UK