Received: by nummer-3.proteosys id <01C19443.4EF63BA4@nummer-3.proteosys>; Thu, 3 Jan 2002 11:42:15 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.4EF63BA4" x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: @ in macro names Date: Sat, 16 Nov 1991 20:31:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 465 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.4EF63BA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>> Dominik's comments on the use of macros with embedded @ signs to >>> represent small constants to save TeX memory reminded me of a = wishlist >>> item I've had for years about TeX macros. >>> I intensely dislike the sprinkling of @ characters throughout macro >>> names; it makes them very hard to read. I would much prefer a >>> systematic scheme that placed @ in only the initial position, so >>> \@zero \@one \@two etc would be used instead. Strangely enough, it is this very use of commercial-at in the LaTeX = source that I find so depressing! Don Knuth seems to go to inordinate trouble = to ensure that his concealed macro names remained pronounceable despite the intrusion of commercial-at, by making (almost without exception) commercial-at represent a vowel; Leslie Lamport, on the other hand, seems to treat it more like a glottal stop, making his concealed macro = names almost unpronounceable ... >>> I agree with Dominik that literate programming expositions of macro >>> packages would benefit from expansion of simple constants. If this = is >>> to be systematized, it may be necessary to adopt certain conventions >>> for macro names, e.g. \c@xxx is a constant named xxx, so that only >>> macros conforming to that syntax would be expanded. But I have considerable sympathy with Nelson's suggestion. >>> Compare the trend in modern programming languages and software = systems >>> to systematize names so as to avoid polluting name spaces, and >>> introduce classifications into the names (e.g. VAX VMS LIB$SIGNAL() >>> versus UNIX signal()). Indeed so. And look what happened when X-windows intruded on the scene; all of a sudden, DEC's corporate philosophy of invariably prefixing = their logical names with $ flew out of the window, and without a = mention (that I can trace) in any release notes, `DISPLAY' suddenly becomes a = reserved logical name ... * Phil. ------_=_NextPart_001_01C19443.4EF63BA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: @ in macro names

>>> Dominik's comments on the use of macros = with embedded @ signs to
>>> represent small constants to save TeX = memory reminded me of a wishlist
>>> item I've had for years about TeX = macros.

>>> I intensely dislike the sprinkling of @ = characters throughout macro
>>> names; it makes them very hard to = read.  I would much prefer a
>>> systematic scheme that placed @ in only = the initial position, so
>>> \@zero \@one \@two etc would be used = instead.

Strangely enough, it is this very use of commercial-at = in the LaTeX source
that I find so depressing!  Don Knuth seems to = go to inordinate trouble to
ensure that his concealed macro names remained = pronounceable despite
the intrusion of commercial-at, by making (almost = without exception)
commercial-at represent a vowel; Leslie Lamport, on = the other hand,
seems to treat it more like a glottal stop, making = his concealed macro names
almost unpronounceable ...

>>> I agree with Dominik that literate = programming expositions of macro
>>> packages would benefit from expansion of = simple constants.  If this is
>>> to be systematized, it may be necessary = to adopt certain conventions
>>> for macro names, e.g.  \c@xxx is a = constant named xxx, so that only
>>> macros conforming to that syntax would = be expanded.

But I have considerable sympathy with Nelson's = suggestion.

>>> Compare the trend in modern programming = languages and software systems
>>> to systematize names so as to avoid = polluting name spaces, and
>>> introduce classifications into the names = (e.g. VAX VMS LIB$SIGNAL()
>>> versus UNIX signal()).

Indeed so.  And look what happened when X-windows = intruded on the scene;
all of a sudden, DEC's corporate philosophy of = invariably prefixing their
logical names with <module>$ flew out of the = window, and without a mention
(that I can trace) in any release notes, `DISPLAY' = suddenly becomes a reserved
logical name ...

        =         =         =         =         * Phil.

------_=_NextPart_001_01C19443.4EF63BA4--