On Thu, Sep 13, 2012 at 12:37:00PM +0200, David Kastrup wrote:
> I am working hard to get expressions like { s4 s\< s1 s\! } parseable
> and recognizable without context, and obliterate the need to write - for
> anything except accent shorthands. This is pretty much unavoidable if
> you want to get music functions and other expressions to behave
> consistently and independently from how the results of calling them are
> going to be used.
I'm afraid that I don't follow this paragraph. Other than
simplifying the parser/lexer code (which is of course a good goal
unto itself), why do we want to avoid writing - for anything
except accent shorthands, and why do we want music functions to
behave independently from how the results of calling them are
going to be used?
(other than the below example)
> One intermediate result is that our Scheme tutorial these days says
> something like
>
>
> 2.8 Inline Scheme code
> ======================
>
> TODO: the example for this section is ill-chosen since
> F = -\tweak #'font-size #-3 -\flageolet
> (note the `-' marking it as a post event) will actually work fine
> for the stated purpose. Until this section gets a rewrite, let's
> pretend we don't know.
>
> The main disadvantage of `\tweak' is its syntactical inflexibility.
> For example, the following produces a syntax error.
>
> F = \tweak #'font-size #-3 -\flageolet
>
> \relative c'' {
> c4^\F c4_\F
> }
>
> Using Scheme, this problem can be avoided.
>
> And the initial TODO stating that the example is ill-chosen is _doubly_
> inaccurate since indeed, not even "For example, the following produces a
> syntax error" is true any more. It just works as expected. And I am
> getting the code where even writing
>
> c4\tweak #'font-size #-3 \flageolet
>
> without any spurious - signs will work since the post-event property of
> \flageolet will transparently pass through. But to make things work in
> that natural manner, I need a consistency between how expressions are
> written and what they mean.
I don't see the big deal here. As you know, I would like to let
people distinguish whether commands affect the previous or
subsequent note without having to memorize all the commands. So I
would actually *prefer* to see
c4-\flageolet
c4\tweak #'font-size #-3 -\flageolet
instead of
c4\flageolet
c4\tweak #'font-size #-3 \flageolet
I think we need to decide what direction we want the syntax to
move in (or indeed, decide not to change the syntax at all!).
> It will still take some time until I have the parser where it provides
> the consistency and power I am striving for with all of the ultimately
> unnecessary complexity driven out, and then it will be quite more
> infeasible on a technical level to sabotage the existing framework
> because it would be much more obvious what sort of things are a bad
> match to then existing facilities and a cause for major usability
> regressions.
That's actually why I think we need to discuss these things now.
As far as I understand it, you are moving in the direction of
using \commands for almost everything. Some of those \commands
affect the previous note; others affect the next note. That lack
of consistency makes it harder for users to learn and use
lilypond.
Is this the direction we want to move in? Maybe yes, maybe no. I
think we need to discuss the possible alternatives, weigh the
advantages and disadvantages of them, and *then* decide whether we
want to move to everything being \commands.
> And it will be much less stressful for me to be able to state "you can't
> have that because it would break what we have, just try for yourselves"
> rather than having to state "it is a bad idea to do that since it would
> stop me from getting us where I see us wanting to go".
Yes, of course a shared project would be much easier with a
benevolent dictator. However, other than a few specific instances
(such as the stable/2.16 branch), I don't think that we *want*
benevolent dictators. A number of people want to discuss syntax
possibilities.
I am not at all certain that I agree with where you see us wanting
to go. I *am* certain that I, and many others, have ideas which
do not agree with where you see us wanting to go. Most of those
other ideas are unworkable, but until we examine each idea, we
won't know if it is actually workable or not.
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
