Re: GOP2-3 - GLISS or not

[David Kastrup]

Graham Percival <address@hidden> writes:

> In general, yes.  But some aspects of our syntax haven't been
> around for a long time -- footnotes, woodwind fingering, compound
> meters, etc.  Do we have the best syntax for those?  I mean,
> maybe David can figure out a way to allow us to write
>   \compoundMeter (3+2)/8
> or simply
>   \time (3+2)/8
> instead of
>   \compoundMeter #(3 2 8)

I'd have done so already, but \time takes an optional beatstructure
argument that is indistinguishable from a compound meter, being a number
list.

> Other than indirectly possibly motivating people to work on
> converters and GUIs from lilypond code, I don't see GLISS as
> adding new features to lilypond at all.  Rather, I'm expecting
> that new development continues as before; after some syntax has
> been around for long enough that we're confident that it's good,
> we declare it as "stable" so that users and programmers can rely
> on it.

Longevity is not a measure for quality.  In particular when we are
talking undocumented language quirks that are not likely to have been
known or exercised.

Documenting is a good litmus test: if writing documentation for some
peculiarity makes your stomach turn, chances are that declaring it as
part of a "stable" set is not doing anybody a favor.

>> * dramatically simplify our parser/lexer code in a way that brings
>> future rewards.
>
> David is working on this.

Somewhat backwards: I am trying to bring future rewards, and when our
current syntax throws a spanner in my works, I try arguing for change by
figuring out the sneakiest way to streamline it.

> Some of his changes will break user code, and some users will be upset
> by this.  I'm trying to make users feel better by phrasing it as a
> "give and take" situation.  Yes, some things will break, but other
> things will have a guarantee of stability -- and the area of stability
> will increase over time.

LilyPond has quite a few areas where the underlying design is of
"poke-with-a-stick-until-it-does-one-job" quality, drive-by coding.
There is little won to "stabilize" on random stuff that is going to make
life harder afterwards and that probably nobody understands or uses
extensively.

>> * dramatically expand our user-base
>
> Syntax stability can't hurt converts and GUIs.  I hope that GLISS
> can indirectly increase our user-base by making it easier for
> people to convert music into lilypond.

And have a good subset of LilyPond they can expect to convert back.

-- 
David Kastrup