[EMAIL PROTECTED] (Phil Taylor) writes:

> >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.

So in (a) and (b) the replacement of `n' is `c', and any length 
specifications are taken from the right-hand side of the macro 
definition (the `target string', if I understand you correctly). This 
is what my current implementation does (phew).

> Actually, thinking about this some more, it would be possible to sort
> the macro definitions into order before expanding them, provided that
> you used a sort algorithm which is guaranteed not to change the order
> of elements which are the same size.  Since the list of macros to be
> expanded is never going to be very big you could just use a simple bubble
> sort.

It's no problem simply to do the replacements in reverse order of 
occurrence. Actually it simplifies my code considerably. The sorting 
business came in because my very first version processed the 
replacements in order of occurrence (rather than reverse order), which 
obviously didn't work with Jack's example, which was all that I had to 
go on at the time. I didn't know about the reverse-order constraint 
until later, and I'm perfectly happy with it if you are.

As I said, the version on my web page does the reverse-order thing 
already.

> 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.

Yes, but you Mac users have BarFly to begin with. I could have coded the
macro preprocessor in C (no Pascal, please ...) but it would have taken
me a lot longer than the two hours or so that I have spent on it so far.

Anselm
-- 
Anselm Lingnau .......................................... [EMAIL PROTECTED]
The problem is the browser bosses spend way too long listening to the young
sprouts in suits in the marketing departments who can barely add 2+2 instead
of listening to real users.     -- Peter Flynn, on math support in Web browsers

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to