Re: GOP2-5 - ly language discussions

[David Kastrup]

James <address@hidden> writes:

> David,
>
> On 23 September 2012 11:06, David Kastrup <address@hidden> wrote:
>
>> ....  Much of the parser work I am doing is of incremental nature,
>> and the overall direction includes keeping existing files working
>> according to expectations as much as reasonable/possible while
>> straightening out and sometimes extending the underlying logic.  This
>> work is generally regarded with total apathy (it is not like it is
>> not spelled out in reviews _if_ anybody could be interested in it) so
>> there is little point in delaying each step by having to create
>> formal proposals and obeying two weeks of silence.
>
> Actually I think the word apathy is unfair, well from my perspective
> anyway; I just don't understand what you are doing technically.

Whatever one wants to call it, the work on the parser consists of
several different things.

a) straightening out things.  Quite technical, not easy to explain.
   More things work as one would expect.  Usually no user-level
   documentation available or feasible.
b) new generic features.  Somewhat abstract.  User-level documentation
   in the extending guide.
c) Making use of them.  Either functional equivalents to previous
   behavior, or extensions.  Not easily associated with the parser
   itself.  Documented in the normal user guide.

> Incremental nature, tidying up, straightening out are all things
> anyone can understand, that. By the time you (seem to) get exasperated
> and fall into language/explanation that I can then understand it does
> get appreciated.
>
> It took me weeks to really see the point of the #{ #} change (and I
> still couldn't really explain it to someone if asked, but I do 'get'
> it).

The point is "I know how to do this in LilyPond, but I need this in
Scheme" -- "No problem".  Without first having to ask "What exactly do
you mean with \"this\"?".

> likewise whatever it is you are now doing with the parser/lexer,
> as evident from the recent gripes and grumbles on the GLISS topic,
> only a few really do get what you are working on.

Well, the current change set I am working on has several targets.

a) pitches and durations are recognized separately as music function
arguments.  This needs to go.
b) there are "closed music" and "open music" expressions as function
arguments and in a few other contexts.  This needs to go.
c) the syntactical type of a music function (music/scheme/event) is
determined at the time of its definition rather than by the value of its
expression.  This needs to go.  The latter is how variables work, and
that needs to be the case for music functions as well.

All of that is somewhat finicky, and it mostly addresses things that are
too technical and ugly to usefully explain in user documentation, so
likely the majority of the changes in the user documentation involve
deleting stuff or no longer having to write it.

Which, in a way, is the best that can happen to documentation.

> Just like Mike and Keith's work; it seems that they are both doing
> 'very useful' enhancements but again, I really don't understand it
> technically. The *only* way that someone like me (and perhaps many
> others who subscribe to the devs list) can appreciate or be able to
> comment is when we're presented with before/after 'output' (either
> graphically or as in Mikes slur stuff, as comparison times - quicker
> is better right?), it's just all a bit abstract for many of us.

Well, my work is more interesting in terms of "before/after" 'input'.
Hopefully the "after" version is less abstract than the "before"
version.

> The only way someone like myself can really show lack of apathy is by
> contributing to the project if not all the patches.

Well, you focus on the word "apathy".  My actual point here was to point
out that I can't wait two weeks for every significant change and that it
would not make all that much sense since on most of the stuff, the input
would be exactly zero.

-- 
David Kastrup