Re: [GLISS] non-timed or non-musical events "z" "y"

[Graham Percival]

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