[frogs] Why are book blocks objects but not contexts in Lilypond?

[Ian Hulin <ian@xxxxxxxxxxxx>]

Hi,

I'm looking at this in terms of design inconsistencies rather than documentation issues.

I've been looking around at the code and documentation regarding contexts and noted these statements:

LM 3.3.2 says

"Note that there is no \new Score command;
the single top-level Score context is introduced
with \score."

(My bolding)

LM 3.1.1 says

"Every \book block creates a separate output file (e..g., a
PDF file).  If you haven’t explicitly added one, LilyPond wraps
your entire input code in a \book block implicitly.

Every \score block is a separate chunk of music within a
\book block.

Every \layout block affects the \score or
\book block in which it appears – i.e., a \layout
block inside a \score block affects only that \score
block, but a \layout block outside of a \score block
(and thus in a \book block, either explicitly or
implicitly) will affect every \score in that \book."

(My bolding)

So, is the top-level block in a lilypond input file implicitly a book or a score?  
Which is right, and do all places in the code make the correct assumption consistently?

There are a couple of parser variables relevant to \book output-count and output-prefix (only output-prefix is still used as of 2.13.4).  I reckon output-prefix and possibly then the filename part of the output filespec would be valid properties for \book.  I also think Book would be a valid context for these to live in.

However, at the moment contexts are designed to be part of the process of translating music source code into final format of some sort (e.g. ..png, .pdf), and are associated with engravers and suchlike.  The Book context  would be concerned with whereabouts that output was headed.

I had been thinking of adding all the parser variables as properties, but have since had a look at the original list Marl Polesky generated and have come to the conclusion parser variables seem to be a very mixed bag:  for things which are supposed to be user-settable this seems to be because maybe the developer couldn't think of a place that fitted for them: afterGraceFraction should have been an optional parameter to the afterGrace function, and output-count and output-prefix should have had some way of being attached to the \book in the lilypond language; showFirstLength and showLastLength are associated with the skipTypeSetting property which LR 3.4.2 lists as a score property so show*Length should be in define-context-properties.scm where skipTypesetting is defined.  The rest of the parser variables look like they are genuine internal things for use in Scheme code.

So, if \book is really the top of the tree, and a lilypond file is either:

• a series of \book blocks
• a single \book block
• an implicit \book block

And each book block of whatever sort contains either:

• a series of \score blocks
• a single \score block
• an undeclared, implicit \score block

Places in the code assuming "a single top-level score context" will need fixing.

I would like lilypond to have a Book context sitting above Score in the context hierarchy.

How could I add Book as a valid context?

I already understand how to add new properties to the lists in define-context-properties.scm.

I haven't yet found out how \set, \unset,  \override or \revert code decides which of the property lists like all-music-properties, all-translation-properties or all-backend-properties to search for a valid property definition.

Thanks in advance for any help, tips, pointers or comments.

Cheers,
Ian Hulin