>> I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What
>> would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of
>> a tune? The interesting point is whether the `n' includes a length or
>> not.
> (a) and (b) will expand, (c) will not, since there is no macro definition
> for that length. 'n' does not itself include the length, but the length
> (if any) is part of the target string.
I wonder if we need two different kinds of macro? I can see the point
of having the length-dependent ones, for the original purpose you had
in mind (ornamentation) but the macros I've written have been about
50:50 ornaments and chords, and for chords the length-dependence is just
a nuisance.
The problem is that since the point of macros is to abbreviate, you want
them to have very short names, which means you have very few options if
you want those names to be at all mnemonic. You can't multiply them at
will.
Maybe it would be better to allow macros to select different behaviour
for different lengths by a pattern-matching or conditional construct?
That way you could reuse the same name for conceptually identical
constructs ("trill" or "mordent" on different lengths of note).
> I wasn't able to test the script, unfortunately. MacPerl has got itself
> into a fankle [...] Us Mac users don't have a lot of fun with perl.
> Every time I try to use it I end up concluding that it would be quicker
> to write a program in C or Pascal to do the job.
I think I've got three versions of MacPerl sitting around on my machines
and none of them ever worked. Python anybody? That does work on the Mac.
(I'd prefer Prolog or ML, both of which I can actually read, but I can't
see there being too many takers for either).
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
