One thing about macroes, however, is that you don't _have_ to use them;
you can fully expand the macro in the source if you want to for some reason.
Your proposal doesn't fit that need, because if I _want_ to write
fff (for fortissimo) in the tune, I can't distinguish it from three f notes unless
I have some delimiters.
In other words, I think we do need to separate out the use of the macro (which in
my opinion should be a literal text substitution) from the issue of the syntax of
special symbols and/or flow control.
However, it seems to me that there is no compelling reason to use a different delimiter
like
!, since it is easy to parse the contents of quoted strings to find out if they are
one of
a
set of reserved words. Any package that doesn't do that will end up treating them like
they
treat "guitar chords".
so instead of
U:J = fermata
use
U:J = "fermata"
(not sure if I've helped here...)
wil
Phil Taylor wrote:
> John Chambers wrote:
> (about the !foo! construct)
>
> >Hmm ... I'd forgotten who didn't like it, of course. The general
> >feature does seem to be inherently useful, so I'd suppose that the
> >objection is to the particular syntax. The other one I've seen is the
> >one that uses double quotes and positioning stuff, as "^segno" or
> >"_da Capo". This strikes me as a usable alternative, though it still
> >does have the problem of confusion with accompaniment chords. People
> >might want to position them too. I suppose you could say that chord
> >symbols can't be positioned this way, and any text with ^ or _ after
> >the " is assumed to be musical annotations.
>
> The placing of guitar chords (above or below the staff) is up to the
> application. You are unlikely to want to change that setting in mid-
> tune. Text annotations do need to be placed differently within the same
> tune, so ^_< and > are needed. Text annotations are just text, they're
> not intended to be interpreted or substituted in the way that user-defined
> symbols and macros are.
>
> >| >But the !foo! notation itself seems simple. And a header line that
> >| >says something like m:q=!foo! seems like it would be trivial to
> >| >implement. ...
> >|
> >| Sure. Just leave out the bangs - they are utterly unnecessary.
> >
> >How so? That would imply that such macros can only be used for this
> >purpose. I couldn't use them to abbreviate other common strings. I'd
> >think a simple "substitute this for that" would be more useful, in
> >which case you'd want the bangs included. Sorta like in C you can do
> >things like:
> > #define begin {
> > #define end }
>
> Fine - but C doesn't force you to write
>
> #define begin !{!
>
> and then go through your code writing exclamation points around every
> brace. That's what is being proposed for abc. The existing abc
> definition gives us the letters H..Z, and they are already in use by
> most programs. Any well-written program will ignore one of these
> symbols that it doesn't understand. You can use them singly or in
> combinations if you really need more than 19 special symbols in one
> tune, and you can define their meanings elsewhere. This has got
> nothing to do with macros - we're not substituting one bit of text
> for another; instead we are choosing which bit of code will be invoked
> when the parser encounters that symbol.
>
> So if I write the definition:
>
> U: J = fermata
>
> then an application which knows how to draw a fermata will draw one
> over a note which is preceded by the letter J, and an application which
> knows how to play a fermata will stretch the duration of the note a bit.
> An application which does not recognise the definition should do nothing,
> and no real harm will be done.
>
> By comparison, writing the word !fermata! in the music makes the line
> eight characters longer than it need be, and makes the abc harder to
> read because it breaks up the flow. This is already the case with
> guitar chords - they make the abc much harder to read because they
> add lots of extraneous symbols to the line of music. I want to limit
> what goes into a line of abc to the important stuff; notes, times,
> bar lines etc which is what you want to read, and compress the other
> less-important stuff into single characters which have less impact
> on the readability. In addition, using !fermata! totally breaks
> programs which don't understand that convention, and the existence
> of large numbers of files which already contain exclamation marks
> (for a totally different purpose) means that it's difficult to
> implement in a way which will also deal reasonably with abc2win
> files. It's not backward-compatible in either sense - old files
> break new programs and new files break old programs. The worst
> of all worlds in fact.
>
> >| Basic substitution macros are very useful, they don't stop you from going
> >| on to deal with macros which know to transpose (which are even more
> >| useful).
> >
> >I've always found that transposing is easiest with a separate program
> >that just does transposing. Builtin transposers in the fancy music
> >packages are mostly good for laughs when they produce totally berserk
> >notation. Thus, I've seen music transposed from F to G, in which all
> >the ^F notes were written as _G, and there were no Fs in the result.
> >The problem with this as a builtin is that when it's broken like
> >this, you can't fix it. If your transposer is a separate program, you
> >can write your own, or grab something like abc2abc, and it's fixed.
>
> I'm not talking about transposition of a whole tune here, I'm talking
> about transposing macros which define the meaning of a musical symbol
> in a pitch-independant way, so that the macro does the right thing
> whatever pitch of note the symbol is attached to.
>
> Phil Taylor
>
> To subscribe/unsubscribe, point your browser to:
>http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
