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

[David Kastrup]

Graham Percival <address@hidden> writes:

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

Because music functions are used to transform expressions.  Functions
like \tweak operate on their arguments, and the arguments don't change
their character.  So it does not make sense to have to remember to
redeclare the type of the expression again and again syntactically just
because a music function has been used to operate on it or generate it.

Everybody gives me hell when I write documentation passages like
"Remember when using xxx, you will have to place @code{-} explicitly
before it when it is used as a post-event, just like you have to do with
@code{\tweak}".  I get shit for all that technobabble and nonsensical
restrictions, yet when I work on making that kind of awkwardness go
away, people tell me that it is not a big deal and they would rather
throw everything accomplished so far away in order to let some random
juxtaposition of existing syntax elements mean something that they could
consider their personal handwriting in the parser.

> (other than the below example)

Because when I bring up actual examples, they don't count.  Or what?

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

Sure.  Making problems go away that previously required using Scheme, to
a degree that nobody can even think of a good tutorial-level problem
that would still require actually meddling with Scheme: no big deal.
Who is interested in that sort of stuff anyway?

> 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

But c4\tweak #'font-size #-3 -\flageolet does not work (yet), and you
want to require - signs where the version without - sign does not even
have any useful different interpretation.  Where is the point?

If you pass expressions through music functions or variables, they won't
remember the way they came about.  They will just remember their value.
And Scheme expressions also don't remember anything but their value, so
the value must include the type.  LilyPond is based on a dynamically
typed language, and on dynamically typed expressions, and if we are
going to pass information in and out of Scheme, everything not tied into
the expressions but rather to the way of using them is going to cause
inconsistencies and hard to remember artifacts.

You don't see the big deal here.  Which is why I am working on that kind
of stuff.  I'm not blind to it.

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

I don't see the point in the repeated threats of locking me out from
what I am working on.  The current state is inconsistent in so many
regards that there is no point in declaring it canonical.

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

Music functions.  Or rather, functions.  I already have a branch where
event functions, music functions and Scheme functions are no longer
syntactically different.

> Some of those \commands affect the previous note; others affect the
> next note.

No.  All functions take arguments to their right, and produce a value.
LilyPond assembles these values in different manners: post-events are
attached to a preceding rhythmic event or event chord.  It does not
matter (or rather it should not, but still does as long as I have not
finished work in that area) whether a post-event expression has been
produced by Scheme, by a variable, by a music function, or by a
post-event expression in LilyPond syntax.  It was not my idea to
introduce post-event expressions into LilyPond.  But regarding the music
function framework, I am tying them into a consistent Scheme where you
can manipulate them _exactly_ like any other expression.  LilyPond will
collect those values differently into surrounding expressions due to
their post-event expression type, but that is not related to how they
have come about, but what they are.

> That lack of consistency makes it harder for users to learn and use
> lilypond.

You can't achieve consistency in a meaningfully helpful way confined to
a surface level.  That's like arranging an art exhibition according to
dominant color.

> Is this the direction we want to move in?  Maybe yes, maybe no.  I
> think we need to discuss the possible alternatives,

Then learn the ropes.  Before that, there will not be a meaningful
discussion.

> weigh the advantages and disadvantages of them,

How can you weigh what you don't understand?

> and *then* decide whether we want to move to everything being
> \commands.

Making functions work consistently and expressively is orthogonal to the
decision whether or not to use them in favor of hardwired syntax.
Making the syntax work consistent with the data representation and flow
also is an independent advantage.  Using the available expressive power
to avoid frequent ad hoc syntax inventions that are a nightmare to
understand, a nightmare to maintain, and a nightmare for third parties
who attempt reading LilyPond code as input is just common sense.

I am not interested in a "decision" of whether to move everything to
functions.  But there is no point in _not_ straightening the relations
between functions, LilyPond input and Scheme until this question
actually makes sense, and where average users can make that decision for
themselves on a case by case basis with confidence.

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

The only alternative I see so far is a benevolent slave.  Nobody is
working on syntax right now except me.  And nobody is interested in
working on it except me.  Instead people are interested in telling me
what I should be doing.  Because obviously I am in desperate need of a
clue by people who are not interested in learning about what is actually
involved.

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

Where is the point in blind people voting on the color of the sky?

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

Wrong.  Until _I_ examine each idea, you won't know if it is actually
workable or not.  And you still won't believe me when I tell you the
price.  Stop examining ideas and start examining the parser, and the
languages, and the data structures, and their relations.  Not all of it
makes a lot of sense, but it gets easier and more straightforward as
long as people let me work on it.

-- 
David Kastrup