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

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Thu, Sep 13, 2012 at 11:39:52PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>
>> > 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.
>
> You have a fundamental misunderstanding of these discussions.  The
> intent is to share ideas, not to bring forward formal proposals for
> language modifications.

"decide not to change the syntax at all" means stopping me from working
on the parser.  I am doing my best within the existing possibilities of
staying upwards compatible, but "no change at all" means just that,
unwanted side effects and all.

>> > 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.
>
> You are not a slave.  Nobody is telling you what you should be
> doing.  Nobody is demanding that you take these discussions
> seriously -- in fact, I have repeatedly told you *not* to take
> them seriously!

If you state that one possible goal is to decide no further changes will
be allowed, and if statements like "I think we need to decide" are
coming from the project leader, it is pretty strange to say I should not
be taking them seriously.

> Most of the ideas are unworkable from the standpoint of
> unambiguous notation of music.  If a human can't understand what
> the syntax means, then of course a computer can't understand it!

But if a human can't understand that he can't understand what the syntax
means, he will try to persuade the computer otherwise, and at some point
of time, people will have a heap of workarounds to maintain that do not
make for a consistent whole.

The usual approach in the backend is to heap exceptions upon exceptions
until the result is more often than not aesthetically pleasing.  And
given the problem space, that approach is not, in itself, wrong as long
as the infrastructure supports this approach since the overall goal is a
complex aesthetic one that is fuzzily defined.

This approach does not work with input syntax.  Not if we want to give
users the tools required for extending LilyPond for their own purposes,
and we want to give them the tools since it means that we also get a
workforce of people helping with extending and maintaining the version
of LilyPond we distribute.

The "extend in arbitrary ways to the point of breakage" approach works
with a fixed, closed, hard-wired syntax, making LilyPond fixed, closed,
and hard-wired.  And that is short-selling its capabilities.

-- 
David Kastrup