.ly: procedural vs. declarative (was: RFC)

[Jan Nieuwenhuizen]

Baron Schwartz writes:

> This may be off-topic, I'm not sure.  I've used LilyPond a bit and it
> engraves music very nicely, however, I have one fundamental difference of
> philosophy that might fit into this discussion: the language for the files
> is procedural, not declarative.  This comes up because someone mentioned
> the constantly-changing syntax -- a serious barrier to wider adoption, no
> doubt!  I believe the syntax changes are because the language is
> procedural; they reflect the changes to LilyPond's internal workings,
> which I see as a bad thing -- it would be better if the user (and the
> input file) could be insulated from that.

Why do you think so, can you give a simple, real world example of how
a past language change would have been less painful in declarative
languages?

> My bias is toward declarative because it encodes information, not
> instructions.  I wrote my thesis on the topic of transforming one format
> into another -- loosely taken, this means "music information retrieval."

In that case, you probably know that converters are easy, if the
source language is documented and parsable, and the target language is
expressive.

> To be most useful, I believe music files ought to simply state *what* is
> there, and let the engraver decide *how* to engrave it.  I know this is an
> over-simplification, but for the sake of brevity I'll leave it at that.

You did not, by chance, devise a nice declarative music langugage?
Would you like to send a little example?

> That said, how about the list of to-do things includes "write
> translators from other formats to LilyPond?"  There are vast bodies
> of work in other formats.

This may be of great interest for the Mutopia project
(mutopia-discuss:
http://lists.blackcatnetworks.co.uk/cgi-bin/mailman/listinfo/mutopia-discuss).
Please consider posting there.  What major bodies do you know of, and
what lisence do they have?

FYI, we currently have this list of translators:

     * import filters: abc2ly, etf2ly (Finale), midi2ly, mup2ly,
       musedata2ly and xml2ly

Most of them are not perfect, but rather a decent first effort.
Again, most of them were written upon receiving a request.  The idea
was they would be used, and bug reports and feature requests would
poor in.  However, I do not have the impression that anyone really
uses them.

Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org