Re: small samples: macros?

Bob writes:

> One thing that occurred to me when looking at your
> recent samples is that "good" TeX authors define macros
> for things like vectors, so they have
> 
> \def\Vector#1{{\bf #1}}
> 
> or whatever, so that they can adjust the formatting at any time
> for all vectors. We use something similar in an an internal
> project and add some type information as well. While I know
> you were asking about the final, expanded expressions, what
> are the plans to allow macros?

The WP does (or will) contain provision for macros.  Bruce will be
providing some more concrete detail about the capability when he has a
chance.  MINSE compounds achieve the same.

It's true, I was asking about the notation one might employ to
indicate font changes within the WP, but I did also want to get at
questions such as yours on how best to handle whatever semantical
information an author might want to transmit.  I see two broad methods
of doing this, via macros and via embedded semantical cues.  My sense
of the difference is roughly

   macro
   -----

     externally: information about macros (such as precedence, renderings,
       semantical cues) is kept in a resource table (I think Dave has used
       the term "knowledge base") indexed by macro names

       vector -> ...


     internally: macro names are then used within the document

       ... and we see that <math>\vector{x}</math> is ...


   embedded notation
   -----------------

     internally: document instances are accompanied by non-rendering
       semantical cues

       ... and we see that <math>&interpretation{vector}&bold;x</math> is ...


Bruce has indicated that he thinks both styles (macros and embedded
cues) will be supported in the WP, although he thought that ultimately
the embedded semantical cues might be handled by element attributes
rather than the sort of operator-style notation above.  Attribute
notation is somewhat different than the operator-precedence style
we're using elsewhere, so it seems to me that the style above might be
used and parsed into attributes, but that's a detail for further
consideration.  (Bruce only commented about attributes in terms of how
the information would be carried in the expression tree; I don't think
he's commented on input form.)  MINSE appears to be driven more
fundamentally by compounds, and I don't recall any comment from Ping
regarding embedded cues.

Macros are more efficient and less cluttering when they occur
frequently within a document.  Modifications to renderings might be
easily achieved with well-done macros.  I think the primary argument
against macros is that some uses can make a document harder to read.
If, for example, in the instance above one wanted to specify that some
vectors come from R^n and some from R^{n+1}, I can imagine wanting to
use the embedded notation rather than 2 different macros.  (And since
the value of n can vary in a paper anyway, listing "the" type of a
macro as an element of R^n is a little phony anyway.)  Or if this
isn't convincing, try to imagine situations where one thinks one has a
reasonable encoding in macros, only to find some odd exception
inserted after development produces an irregularity and hence a need
for either a new macro or a modification of the encoding which
appeared neat.  This is only an argument which says that embedded cues
are good for ad hoc, one-off, or less-regular situations.

In some ways, the embedded cues are simply general annotations which
one might want, as you suggest, for editorial comments.  The question
then might be whether one considers the cues naturally "mathematical"
or "textual", and I think I'd answer "textual".  "context" (in the
sense of OpenMath) information seems textual, although type-theoretic
information might be mathematical (in the sense of involving
mathematical notation as in C^{k+1}).  (But do you (Bob) forsee
employing mathematical notation in type-theoretic information?  I know
you want the cues to be simple, but something like "vector" alone
strikes me as unuseful to a CAS.  I realize you didn't claim "vector"
as being complete type-theoretic information.)

I mention the value of embedded notation partially because I think
that macros are beguiling (not to mention wrong when they are used to
allow variation in rendering, but fudge their supposed semantical
parts, as with the vector example above).  The extra vocabulary they
introduce and their distance between instance and specification can
lead to headaches.  The number of papers AMS has received wherein an
author has done a truly helpful job to AMS with his/her macros is very
small.  I think it's valuable to focus on what we want the notation
to be and to carry, then specify afterward what macro techniques are
allowable.  Macros will be useful when standards are followed, but
I suspect they'll only be useful to an author when they're out of
an author's head.

What I'm saying may be no different than what others would say.

-Ron