Valentin Petzel <[email protected]> writes:
> Am Samstag, 1. Juli 2023, 18:48:31 CEST schrieb David Kastrup:
>> The funny thing is that I suspect Han-Wen might still be surprised to
>> hear what Staff.property "actually means".
>>
>> It's been around for quite longer than its "actual meaning". But of
>> course I should be the last person to complain about my retconning
>> making headcanon.
>
> Hello David,
>
> It is not my intention to confuse Han-Wen, when I say "actual meaning"
> I mean it in the sense "how Lilypond handles this expression
> internally", not "this is the official reading of this expression and
> has been this way since the beginning".
This wasn't a critique at all, more a musing about how the input syntax
of LilyPond changed rather little compared to the changes of its
_meaning_.
Staff.property did not have any inherent meaning. It was part of the
hardwired syntax of \set and \override (in the form of, say,
\override Staff.TimeSignature #'stencil = ##f ) but there was no
user-accessible representation of it outside of the commands.
Music functions like \overrideProperty used syntax such as
\overrideProperty NonMusicalPaperColumn
which actually was equivalent to
\overrideProperty #"NonMusicalPaperColumn"
or
\overrideProperty #"Score.NonMusicalPaperColumn"
and picked apart their string argument, converting it into symbols.
> I’m not even qualified to talk about such things becaus I have not
> been around that long, my first version of Lilypond I used was 2.18,
> and at that point I had absolutely no understanding of how Lilypond
> works ...
Well, my (admittedly badly made) point was that significantly before
2.18, there was not a lot to understand about the correspondence of
LilyPond's input syntax and Scheme because the input syntax was ad-hoc.
At that time, the Bison syntax diagram gave a pretty good impression
about the content of a typical LilyPond input file.
Nowadays, the vast majority of what was ad-hoc syntax at one point of
time has become reflected by music functions and commands like \time are
no longer to be found in the syntax.
In 2.14, syntactic expressions in the parser were a large variety of
different C++ types, so even in the syntax tree itself, partial
productions might not have had a Scheme equivalent. Since 2.17.3, every
syntax production in the parser is represented by a Scheme expression.
But on the surface, LilyPond input syntax changed very little, so
someone who _knows_ all of the old syntax (like Han-Wen who made up the
majority of it) has less benefit from "understanding" it than comparable
newcomers have.
That's what I called "retconning": tweaking an existing "story" about
LilyPond and Scheme in a manner that makes more sense than it was
designed to start with, and see how it helps people understanding and
teaching about LilyPond.
Yes, I probably was being smug. It wasn't supposed to be at the expense
of anyone. Sorry if it came across as such.
--
David Kastrup
