Re: [abcusers] About BarFly m: macros

[Jack Campin]

> I think that m: is a wonderful and very useful extension to the standard,
> but AFAIK BarFly is the only program that supports it. In my view, macros
> shouldn't be part of the notation, and should be implemented using
> external tools like preprocessors. But that's just an opinion. I think
> I'll extend abcpp to add m: support.

Anselm Lingnau (I think) did a Perl implementation and posted it here
a few months ago.

I am not totally happy with macros as they are in BarFly at present;
perhaps if somebody took Anselm's implementation and stuck it into
another implementation, user input evolve something better.  (The
particular problem I have is that by far my commonest use for macros
is to abbreviate chords in triadic keyboard bass parts, and the
present setup means I have to write a new macro for every duration
I use.  The mechanism understands the pitch modifiers _=^', as part
of the note, but not the duration modifiers like numerals and /).

-
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
 * food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
--> off-list mail to "j-c" rather than "abc" at this site, please <--


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

Re: [abcusers] About BarFly m: macros

[John Chambers]

Guido Gonzato wrote:
| On Wed, 2 Jul 2003, I. Oppenheim wrote:
|
| > > m: ~n3 = n{o}n{m}n
|
| I think that m: is a wonderful and very useful extension to the standard,
| but AFAIK BarFly is the only program that supports it. In my view, macros
| shouldn't be part of the notation, and should be implemented using
| external tools like preprocessors. But that's just an opinion. I think
| I'll extend abcpp to add m: support.
|
| That said, if all developers are willing to implement m: in their
| programs, that't fine. Otherwise, abcpp will do the job for them.

Macros are usually best handled by  a  separate  pass  that
just expands them.  One of the interesting things about the
history of C is that there were  a  few  compilers  written
that had the macros integrated into the language.  This was
generally considered a bad idea.  In some cases, the  macro
code  was  stripped  out,  and replaced with a separate cpp
pass.

In the case of the C pre-processor, one of the  interesting
arguments  was  that the pre-processor is useful with a lot
of other languages.  If you look at C's macros, they really
have  little  to  do with C.  About the only syntax that is
really "C" is the /*...*/ comment; the rest is generic  and
works  with most other languages.  This was especially seen
when the Berkeley folks came out  with  the  compiler  with
multiple  parsers,  so  the  same  compiler could handle C,
Fortran and Pascal. New parsers could be (and were) written
as  plugins.  The macro phase was done first, so C's macros
could be used with all of the languages in the list.   Perl
has  an option to run the code through cpp.  So keeping C's
macros in a separate program is a  benefit  to  many  other
languages.

It's not obvious that abc macros would be  very  useful  to
anything  but  abc.   The  above  macro is pretty obviously
musical, and of  no  obvious  use  anywhere  else.   But  I
wouldn't  be  too  surprised if people found other uses for
it.  In any case, one of the vague and general lessons from
the  field  of  computing  is  that  things  that  do  text
transformations like this are often more  useful  than  you
think  at  first.   They  are  best  done  with  standalone
programs, so you can easily retarget them.  You can  invoke
them  by  default (as C compilers do) or with an option (as
perl does), but you probably  don't  want  them  integrated
into your other programs.

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

Re: [abcusers] About BarFly m: macros

[Richard Robinson]

On Thu, Jul 03, 2003 at 09:03:24AM +0200, Guido Gonzato wrote:
> On Wed, 2 Jul 2003, I. Oppenheim wrote:
> 
> > > m: ~n3 = n{o}n{m}n
> 
> I think that m: is a wonderful and very useful extension to the standard,
> but AFAIK BarFly is the only program that supports it. In my view, macros
> shouldn't be part of the notation, and should be implemented using
> external tools like preprocessors. But that's just an opinion.

I suspect this may be one of those "Linux user" things, and people who
use software that gives them buttons to push may be less comfortable
with such an approach ?


> That said, if all developers are willing to implement m: in their
> programs, that't fine. Otherwise, abcpp will do the job for them.

Which is nice :)

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem

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

Re: [abcusers] About BarFly m: macros

[Guido Gonzato]

On Thu, 3 Jul 2003, Phil Taylor wrote:

> That's a bit Linux-centric, Guido.  Remember that in a GUI program,
> the text editor, preprocessor and abc parser are all part of the
> same program, and you can't just use an existing external preprocessor.

sure! But you can mimick this arrangement decently well. For example, in
my JedABC the user may be tempted to ignore that the editor is using
external programs. Everything appears as if it were part of the editor; I
was actually inspired by your BarFly when I started designing JedABC.

I may also write a GUI, multiplatform version of abcpp using the FLTK
toolkit. This would benefit all users, not only those who use JedABC or
command line programs.

> In any case, if properly written, abc containing macros will still work
> whether or not the macros are expanded, so they can be treated as an
> optional extra.

I'd say I agree with you.

later,
  Guido =8-)

-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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

Re: [abcusers] About BarFly m: macros

[Phil Taylor]

Guido Gonzato wrote:

>On Wed, 2 Jul 2003, I. Oppenheim wrote:
>
>> > m: ~n3 = n{o}n{m}n
>>
>> Phil, thank you for sharing this, this is a wonderful
>> idea! I strongly suggest to include this mechanism in
>> the upcomming standard. Guido, what do you think?
>
>My personl view is that extensions are always welcome if the make life
>easier, but calling them 'standard' is only possible if/when they are
>actually implemented by a large number of applications. Remember, I
>believe in 'de facto' standards.
>
>I think that m: is a wonderful and very useful extension to the standard,
>but AFAIK BarFly is the only program that supports it. In my view, macros
>shouldn't be part of the notation, and should be implemented using
>external tools like preprocessors. But that's just an opinion. I think
>I'll extend abcpp to add m: support.

That's a bit Linux-centric, Guido.  Remember that in a GUI program,
the text editor, preprocessor and abc parser are all part of the
same program, and you can't just use an existing external preprocessor.

>That said, if all developers are willing to implement m: in their
>programs, that't fine. Otherwise, abcpp will do the job for them.

OK.  There is already a perl script which expands macros; it was written
by somebody on this list, but unfortunately I've forgotten who, or
where it is.

If anybody is thinking of writing a preprocessor for this purpose, take
a look at  for a
more detailed description.  The code isn't difficult, and I would give
it away, but since it's in Pascal and uses some Mac toolbox calls I
don't think anyone here would find it useful.

In any case, if properly written, abc containing macros will still work
whether or not the macros are expanded, so they can be treated as an
optional extra.

Phil Taylor


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

Re: [abcusers] About BarFly m: macros

[Guido Gonzato]

On Thu, 3 Jul 2003, I. Oppenheim wrote:

> It's fine if it's handled by a preprocessor, but it
> still should be part of the standard. In C, #define is
> also part of the ANSI-C standard, although it is
> actually implemented in a preprocessor.

you hit the bull's eye. Good, I'll mention m: too.

Ciao,
 Guido =8-)

-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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

Re: [abcusers] About BarFly m: macros

[I. Oppenheim]

On Thu, 3 Jul 2003, Guido Gonzato wrote:

> I think that m: is a wonderful and very useful
> extension to the standard, but AFAIK BarFly is the
> only program that supports it.

I'm fair enough to admit that BarFly is a widely used
and significant ABC program; so if Phil says that his
macro facility is well-defined and documented, and
proven in practice, I think that's enough to include it
in the standard.

I'm convinced that it's a useful feauture. I'm also
convinced that when it get's into the standard, most
packages will start to support it within a year or so.
In the meantime, your preprocessor could be used to
handle the macros.

> In my view, macros shouldn't be part of the notation,
> and should be implemented using external tools like
> preprocessors.

It's fine if it's handled by a preprocessor, but it
still should be part of the standard. In C, #define is
also part of the ANSI-C standard, although it is
actually implemented in a preprocessor.


 Groeten,
 Irwin Oppenheim
 [EMAIL PROTECTED]
 ~~~*

 Chazzanut Online:
 http://www.joods.nl/~chazzanut/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] About BarFly m: macros

[David Webber]

From: "Guido Gonzato" <[EMAIL PROTECTED]>

> My personl view is that extensions are always welcome if the make
life
> easier, but calling them 'standard' is only possible if/when they
are
> actually implemented by a large number of applications. Remember,
I
> believe in 'de facto' standards.

In the case of the m: macro given by Phil, the solution is easy.
Just document the existence of m: as something that goes beyond the
standard (if you don't want to include it), and programs can either
use it or not.

The key is (in this example at least) that the music makes
syntactical sense if you ignore the macro.  If all macros are like
that and the existence of m: is documented, it will ensure that
macros do not break programs which ignore them.

Dave
David Webber
Author of MOZART the music processor for Windows -
http://www.mozart.co.uk
Member of the North Cheshire Concert Band
http://www.northcheshire.org.uk


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

[abcusers] About BarFly m: macros

[Guido Gonzato]

On Wed, 2 Jul 2003, I. Oppenheim wrote:

> > m: ~n3 = n{o}n{m}n
> 
> Phil, thank you for sharing this, this is a wonderful
> idea! I strongly suggest to include this mechanism in
> the upcomming standard. Guido, what do you think?

My personl view is that extensions are always welcome if the make life
easier, but calling them 'standard' is only possible if/when they are
actually implemented by a large number of applications. Remember, I
believe in 'de facto' standards.

I think that m: is a wonderful and very useful extension to the standard,
but AFAIK BarFly is the only program that supports it. In my view, macros
shouldn't be part of the notation, and should be implemented using
external tools like preprocessors. But that's just an opinion. I think
I'll extend abcpp to add m: support.

That said, if all developers are willing to implement m: in their
programs, that't fine. Otherwise, abcpp will do the job for them.

Ciao,
 Guido =8-)

-- 
Guido Gonzato, Ph.D.  - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri

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