[EMAIL PROTECTED] writes:
> > notation is not well defined,
>
> Hmmm. Are you referring simply to the fact that notation is
> incomplete? That it leaves certain things unsaid? Or is there some
> more serious problem with the notation?
If you can point me to one a more or less formal definition of
notation, I'd be very grateful. Music notation has weird things like
`key': it adds state to the notation and it makes non-diatonic music
come out weird. And because of its evolutionary nature (notation
evolved from notation for single voice music), advanced things are
hairy to express: for example, look at complicated keyboard music
(Ravel, Debussy. I think Byrd's paper in CMJ lists some of the things
notation can lead to). There are three different ways to notate
concurrency (multiple heads, multiple stems, multiple staffs).
>
> > and has more or less evolved in 1000
> > years to a rather complicated system. So, when you want to teach
> > people about entering mudela (ie., defining music), I would like to
> > avoid mentioning this broken system (notation) for defining music.
>
> How can you reconcile this with saying "quarter note" in the system
> then? No matter whether you claim "a4" is a quarter note, represents
> one, produces one, or whatever, that still seems like a reference to
> the notation.
IMO, music is about sound. A note is a sound of a fixed pitch and
finite duration. Does this definition have any reference to notation?
>
> > > I must admit that the way things are currently set up seems
> > > overcomplicated. Why not admit as a lyric anything that doesn't start
> > > with a number or whitespace and doesn't look like "\" followed by an
> > > alphabetic character?
> >
> /home/adrian/test.ly:6:32: error: have to be in Lyric mode for lyrics:
> \type Lyrics \lyric{ foo4 bar8
> foo8}
>
> I was unable to figure out WHY this message would occur. Undoubtedly
> someone who actually understood how these things work could this
> change more easily.
I think you might have forgot to account for { and } who also conform to:
anything that doesn't start
with a number or whitespace and doesn't look like "\" followed
by an
alphabetic character?
The reason that we can't do it is this: it sucks, using the rule
"anything that doesn't start with" implies that we can't add any new
constructs to the language, since they would be interpreted as lyrics.
You might want to experiment with
ANDREWLYRICS ([^ \n\t\f\\{}<>0-9";.|]|\\[^a-zA-Z]])[^0-9 \t\n\f]
I gave up when I realised it is a silly thing to do.
> Well, I don't think it's superfluous. I suppose I could include
> lily/parser.yy directly in the documentation but it's 1400 lines long
> and my grammar is 34 lines long. The grammar in that file doesn't
> generalize.
[..]
> If you can't document your language more efficiently than with this
> 1400 line grammar, then clearly something is seriously wrong.
Clearly, the grammar needs generalization. I don't see the usefulness
of grammars that are incomplete and fuzzy (and yes, I am guilty too).
A formal specification is not very useful if its not the Real Thing.
> The difficulty in making a basically correct, concise grammar for
> mudela points to various inconsistencies in the underlying language.
> I think that it would be worthwhile to ponder these inconsistencies.
> Unless there is a good reason for an inconsistency, it should be
> eliminated. And each inconsistency should receive specific thought
> and justification for its existence.
Yes. Please do so; and having a concise grammar is important for me
too, not because of the explanation difficulties, but simply because a
shorter grammar makes for shorter code.
I am sorry if my reply really sounds like `do it yourself' all the
time, but for me it is really much easier for me to work on some of
your code (and see that your code improves the parser), than to try to
interpret your writing. I think that already lost some meaning when
you converted your thoughts to writing, and you are probably the best
person to know what (in your opinion) could be improved in the
language.
Besides, I have been deformed by 2 years of coding on LilyPond.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
