This response is a bit late. I'm recovering from a hard-disk
crash and suddenly find myself 150 messages behind--so if what I'm going
to say has been covered, apologies.
John Chambers wrote:
>
>Another part of the problem is that when we've discussed
>the issue in the past, it has often led to flaming
>outbursts from people debating their idiosyncratic
>definition of the term "macro", usually in terms that make
>absolutely no sense to the other participants. It's obvious
>that some people thing the others are idiots, but can't
>seem to explain what they're talking about in terms that
>the other programmers understand. This does not bode well
>for any general guidelines on how to handle this topic in a
>fashion that's useful to non-programmer musicians.
>
Ah yes, the M word. I think I added my own bit to the confusion,
tho not, I hope, to the flames. What is clear is that there are a couple
of definitions of "macro" floating around. They overlap but don't
coincide; and there are a couple of different types of "macro" in abc
which fit into one definition but not the other.
The subject seems to be returning, carrying its usual confusion,
so I looked up the definitions to see what they said.
First, in my on-line Websters, a macro is defined as:
macro n, pl macros [short for macroinstruction] (1959): a single computer
instruction that stands for a sequence of operations.
However, the new Hacker's dictionary defines it:
macro /mak'roh/ techspeak n. A name (possibly followed by a formal arg
list) which is equated to a text or symbolic expression to which it is to
be expanded (possibly with the substitution of actual arguments) by a
macro expander.
There's more---I'll get back to that---but note that there is
quite a difference in the two definitions. Webster's definition is pretty
general while the Hacker's definition is more specific: it tells you not
only what a macro is, but how it is accomplished (by a macro expander).
Kind of strange if you think of it---if you wanted to be really careful
(perish the thought!) you'd say that a macro was an ordered pair, macro
plus expander. On the other hand, the hacker's definition is not limited
to "instructions," while Webster's is. There is a third definition that
I've heard on this list: a macro is a text substitution.
I'd always understood "macro" in the Webster's sense, having run into them
principally in TeX and in keyboard macros for text editors, so I was
surprised when this usage led to confusion. Now I understand why.
The jargon file goes on to say,
"Indeed the meaning has drifted enough that the collective
'macros' is sometimes used for code in any special-purpose application
control language (whether or not the language is actually translated by
text expansion), and for macro-like entities such as the 'keyboard macros'
supported in some text editors (and PC TSR or Macintosh INIT/CDEV keyboard
enhancers)."
The confusion in abc comes from the fact that there are a couple
of types of macros (or "macro-like entities") floating around: First,
Phil Taylor's Barfly macros seem to fit the Hacker's definition nicely.
(Even his transposable macros fit, since the definition allows arguments,
and these take a note as an argument.)
However, there is another kind of m-le which is used in abc2mtex,
and has been there since very early versions. (This program might be
thought obsolete by some, but not by me, since I need these things, and
that's the only program that offers them.) For those only familiar with
abc2ps, abc2mtex is a front end for TeX/MusiXTEX, which itself has an
extensive macro facility; MusixTeX can print out quite good staff music,
including symphonic scores if you want them. The way the m-le works in
abc2mtex is this: when you need something not offered by abc, you can
write a TeX macro which will do it, and then attach it to one of the
letters H--Z. When abc2mtex encounters that letter, it simply passes the
name of the macro on to TeX (Sometimes adding the note as an argument).
Then TeX expands it when it processes the abc2mtex output.
I naively called these "user-defineable macros" but of course,
they are not text substitutions; so if you take "macro = text
substitution" as a definition, they are not macros...in abc. And in fact,
they can do things that can't be done by abc itself, since they tap the
resources of TeX. However, *in TeX* they are macros by anyone's
definition, since (as far as I know) TeX macros are accomplished by text
substitutions in the music.tex file that TeX handles. This is the kind of
nit-picking difference which practically guarantees a misunderstanding.
Note that this type of macro (or m-le) could be used whenever abc
is used as a front end for another program which itself has a macro
facility. I'm sure they could be adapted to abc2ly, for instance.
But they could also be incorporated in abc itself, although this
would require some fairly radical development, such as the creation of a
built-in macro language.
Anyway, the point of this long note is not to clear up the
definition of macro---I think that's pointless---it's just to call
attention to the fact that there a couple of possible usages of...aah,
should we say, "macro-like entities"...which are already embedded in abc.
(But not in the abc standard since nobody could agree on what a macro
was...)
I'll stop there---too much explanation confuses the issue further,
and I may have already gone too far.
Oh, yes, one more thing: the macro discussions John Chambers and I
referred to occurred on a sub-list attempting to develop a new standard,
and probably contributed its small share to the general debacle. Since
most of the members of abcusers were lucky enough to miss that, and might
wonder what happened, let me summarize the (abc2mtex part of) the macro
discussion as it appeared to me:
"...and that's how abc2mtex macros work."
"But those aren't text substitutions."
"Of course not, they're macros!"
Cheers,
John Walsh
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
