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

[David Kastrup]

Graham Percival <address@hidden> writes:

> 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 ?!

Reality check.  Everything you do needs a representation in Scheme.

> I honestly had no idea that this was an overall goal.

It is not a goal but a necessity.

> 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.

Well, music functions are also basically preprocessing.  However,
preprocessing that mixes up the order of elements has quite funny
consequences regarding the continuity of \relative, of chord repeats, of
autochanging, of voice creation, part combining and so on, because that
happens to a good degree at subsequent layers.  Music functions are a
reasonably transparent and predictable transformation.

> I'm not fond of prefix functions; that's why I didn't care for
> your \at function.

LilyPond does not have anything but prefix functions.  Event functions
don't get to see the preceding expression as an argument: they just get
attached to them when LilyPond sweeps up the whole kaboodle, but they
don't get to operate on them.  It is rather the job of the preceding
expression itself to collect them usefully, so that is again a prefix
operation.

> 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.

If functions look back and forth, and manipulate forwards and backwards,
the resulting parser complexity, both programming it as well as
understanding the results, will be horrendous.

> 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.

The difference is that LilyPond is a live, extensible and well-defined
system.  You don't need to mess with the language in order to create
good shorthands for any given task.  That does not mean that messing
with the language is inappropriate for some things.  Or impossible to
do.

Take a look at the \tempo command.  Everybody and their dog tells me
that this is just what a musician wants in syntax.  Whenever I do
significant work on the parser, \tempo pitches in with a few dozen
reduce/reduce errors and takes an hour of extra time.

Add a few dozen things musicians think the greatest thing since sliced
bread, in the usual "poke things with a stick until the regtests pass"
programming style popular among LilyPond programmers, and you may as
well declare the syntax fixed.  You won't be able to make progress
without breaking more things than you can improve.

I don't want to go there.  But every single step down the slippery slope
may seem doable if you don't think too hard about it.

-- 
David Kastrup