On Thu, Sep 13, 2012 at 08:56:26PM +0200, David Kastrup wrote: > > Graham's and my suggestions are very restrictive, and we are just > > playing around with possible syntax forms. > > How about considering how they are supposed to translate to and from > Scheme?
Woah. Is the syntax supposed to support translating from scheme to .ly ?! I honestly had no idea that this was an overall goal. I'm not being snarky; I really had no clue. That would, of course, change things drastically. In particular, it would sink the "easy implementation"[1] of the -{ s4 ... } idea. [1] basically, do the translation -{ ...} as a one-directional pre-processor step; I could write a python program that would do the replacement before passing the .ly file to the main lilypond binary. If that's intended, then I should add it here: http://lilypond.org/~graham/gliss/gliss_1.html > > It would be tremendously helpful if you can show possible syntax > > *alternatives* instead of just pretending to be a naysayer. > > I've posted actual working definitions for that purpose. They would > definitely simplify the kind of entry you are asking for. However, > nobody can be interested in them since they don't necessitate parser > changes. I'm not fond of prefix functions; that's why I didn't care for your \at function. Now, if a music function can apply to the current note, i.e. c1-\at{ s4 s s\f s } then I'd be much happier. However, perhaps there's a larger issue here. Maybe it's time to follow the example of TeX and LaTeX -- we could create a pared-down, easily scheme<->ly representation format (e.g., following David's plan (almost?) exactly). Then a separate group of people (me, Janek, etc) could define an additional format as a pre-processor step. That other format (ly2 ?) would have an unambiguous representation in ly, but we would not be concerned about going from ly to ly2. In terms of code sanity, the ly2ly (ok, it would need a better name than "ly2" !) translator could be done in a completely separate language (python, scheme, whatever) and would create a .ly file in /tmp/, which is then processed by the usual lilypond parser. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel