[GLISS] turning strings to symbols (was: Issue 2883)

[David Kastrup]

Copying to a wider distribution of people who only sporadically write on
lilypond-devel (I hope I have most of the others covered via
lilypond-devel) since I need feedback on this.  Issue 2883
<URL:http://code.google.com/p/lilypond/issues/detail?id=2883> deals with
a mostly (apart from half a dozen music functions that usually get an
extension in functionality at the price of non-upward-compatibility)
upwards-compatible change in syntax that may have drastic repercussions
on what syntax we want people to use.

In a nutshell, things like
\override Staff.TimeSignature #'bound-details #'left = #42
(it is obvious that I don't quite remember what I am talking about) are
equivalent to
\override #'(Staff TimeSignature) bound-details.left = #42
or (what we might want to actually promote)
\override Staff.TimeSignature bound-details.left = #42

And the same equivalences basically hold when you are calling functions
that expect to see a list of symbols as argument.  That basically makes
it possible to obliterate usage of #' from many LilyPond programs and
means that users are not generally required to know the difference
between symbols and strings and when to use which.

This requires quite a bit more of type-checking in the parser, but it
turns out that this is not a performance problem since it beats invoking
the Scheme reader and interpreter for such expressions hands down.

I need feedback.  Read on.

James <address@hidden> writes:

> I'm trying to run patchy and getting
>
>
> Trying issue 2883
> Warning: something went wrong; omitting patch for issue 2883
> No new patches to test
[...]
> Can you at least run ./test-patchy and see if you get the same
> immediate warning?
>
> Not asking you to test it, but that you get the same as me.

Sure, that's what comment #6 is about
<URL:http://code.google.com/p/lilypond/issues/detail?id=2883#c6>.

I have checked the regtests myself (you can get this from the
origin/dev/syntax branch), they compare fine.  (Unfortunately, they
already compared fine when the footnote conversion lead to dropped
per-Staff footnotes, so either footnotes pass under the radar of the
comparison script selecting the graphical comparison candidates, or our
regtests are not exhaustive enough.)

The doc compilation drops out in the German translation as the pre-2.16
\footnote description throws errors (rather than just being non-working
non-sense like it is now) after the conversion.

This patch was _supposed_ to be huge (due to a really invasive
convert-ly rule) in order to demonstrate the kind of syntax we can
consistently use in future if we want to.

I'll try reworking the material to a state where the convert-ly
conversions will be restricted to those music functions where the new
syntax is not upwards-compatible with the previous one.

The current state of the branch is

address@hidden:/usr/local/tmp/lilypond$ git diff --shortstat origin..HEAD 
 692 files changed, 7432 insertions(+), 7196 deletions(-)

and the contribution of the last convert-ly commit is
 687 files changed, 6838 insertions(+), 6879 deletions(-)

so there is some leeway for making the _code_ easier reviewable.

But the _point_ of the _invasive_ patch and convert-ly rules was to get
feedback about what people think about a language change that
essentially makes it unnecessary for users to write symbols like #'xxx
or to even know the difference between symbols and strings, regardless
of whether we are talking about using commands hard-wired into the
parser or music functions.  And of course also to give \override-like
music functions the option to get input like Staff.TimeSignature
delivered as #'(Staff TimeSignature) automagically.

So far, the attempt to get feedback on this language change has failed
spectacularly, but that is the point of the current review at
<URL:http://codereview.appspot.com/6635050>.

So I'd reask people to look at this change either on the Rietveld review
or in git in the origin/dev/syntax branch
<URL:http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/syntax>,
in particular the impact of the last commit by running convert-ly.

And give their opinion about what does not quite constitute peanuts in
the GLISS area.

-- 
David Kastrup