Re: how to make decisions?

[Han-Wen Nienhuys]

On Tue, Sep 4, 2012 at 5:03 AM, Trevor Daniels <address@hidden> wrote:
>>>> I don't know where to go from here.  I spend a lot of effort
>>>> trying to organize such discussions, because I think that LilyPond
>>>> is a community project.  I think that we should encourage people
>>>> to participate, but telling people "ok, thanks for your work on
>>>> XYZ, now get lost while the real developers talk about ABC" might
>>>> discourage people from working.
>>>
>>> It did.
>>
>> No doubt.  And I don't want to promote a setup which will essentially
>> end up as exactly that when viewed honestly.
>
> [snip]
>
>> I am doing the best I can, but I don't really see how I can justly deny
>> the underlying gist of the characterization "ok, thanks for your work on
>> XYZ, now get lost while the real developers talk about ABC".  And I want
>> to avoid creating organizational structures that will cause exactly that
>> impression if I am trying to do serious work according to the best of my
>> conscience.
>
> David, it wasn't anything /you/ said; it was Han-Wen's reply which
> dismissed my cautionary offering as "bed-shedding" and referring
> to a sneering video about other syntax failures.  Which, incidentally,
> illustrated my real point (which he missed) ideally.

I'm sorry - I have been doing these kinds of syntax discussions for
too long, and have too little time for them now.

The video is intended to illustrate how a small features of a language
may make sense (ie. was created with the best intentions) when viewed
on small scale, but makes the language as a whole confounding.  For
javascript, for example, + can implicitly convert to string, which is
neat for applications which do a lot of string manipulations, but it
has the side effect that

  [1,2] + [2,3]

evaluates to

  "1,22,3"

rather than

  [1,2,2,3]

which is surprising to many programmers.

More to the point of lilypond, I'm trying to get across that the
problems of new syntax constructs are usually not in the examples that
motivate them, but rather in other areas of the language. An example
that passed the list recently is
having digits in identifiers, breaks compaitbility since \skip4 now
would be a identifier dereference.

My request for having parser patches is also grounded in this. Basic
problems with most syntax changes become readily apparent if you try
to change the parser grammar; since they often lead to ambiguities
which Bison cannot resolve.

Such considerations make me skeptic of changes that are explained by
way of example, especially if they have a broad impact. Such changes
can often not be implemented sanely.

If I missed your point, can you state it more explicitly?

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen