Make \header blocks tangible in Scheme

Make \header blocks tangible in Scheme

This treats Guile modules and \header blocks as more or less
equivalent.  Since \header blocks also contain module imports that
might not concur with those at the place of use, any use of a module
in place of a \header merely copies the values of the module
variables.  Consists of the commits:


Admit \header-like expression into \score


Admit \header-like expressions in \header


Admit \header-like expressions at top levels

\header-like expressions are allowed at \book, \bookpart,
and top level.


Allow \header blocks in expressions

This allows creating modules for further programmatic manipulation.

[thomasmorley651, 2016-06-28 17:09:04]

Can't review the code.
From description: very nice.

Though, I'm not sure to which grade coding (with) header-expressions will be
extended.
Meaning, how about an entry in changes and/or snippets?

[dak, 2016-06-28 17:29:19]

On 2016/06/28 17:09:04, thomasmorley651 wrote:
> Can't review the code.
> From description: very nice.
> 
> Though, I'm not sure to which grade coding (with) header-expressions will be
> extended.

Complete?  Try finding something that doesn't work.

> Meaning, how about an entry in changes and/or snippets?

Changes, regtests, snippets, documentation.  All that would be warranted and
required, turning this from a 60-line change to a 1000-line change, and that's
before translations.  But that's not the main problem for me.  The main problem
is that the feature itself is straightforward and obvious, but examples and
descriptions are arbitrary and there are thousands of different ways to tell the
story.

And whatever way I pick is sure to be substantially rewritten anyway.  So it's a
bit of a fight for me to muster the energy for the first shot at it.

[pkx166h, 2016-06-28 18:16:05]

On 2016/06/28 17:29:19, dak wrote:
> On 2016/06/28 17:09:04, thomasmorley651 wrote:
> > Can't review the code.
> > From description: very nice.
> > 
> > Though, I'm not sure to which grade coding (with) header-expressions will be
> > extended.
> 
> Complete?  Try finding something that doesn't work.
> 
> > Meaning, how about an entry in changes and/or snippets?
> 
> Changes, regtests, snippets, documentation.  All that would be warranted and
> required, turning this from a 60-line change to a 1000-line change, and that's
> before translations.  But that's not the main problem for me.  The main
problem
> is that the feature itself is straightforward and obvious, but examples and
> descriptions are arbitrary and there are thousands of different ways to tell
the
> story.
> 
> And whatever way I pick is sure to be substantially rewritten anyway.  So it's
a
> bit of a fight for me to muster the energy for the first shot at it.

So I guess a tracker for now would be good enough or should we wait some more?

James

[dak, 2016-06-28 18:26:44]

On 2016/06/28 18:16:05, pkx166h wrote:
> On 2016/06/28 17:29:19, dak wrote:
> > On 2016/06/28 17:09:04, thomasmorley651 wrote:
> > > Can't review the code.
> > > From description: very nice.
> > > 
> > > Though, I'm not sure to which grade coding (with) header-expressions will
be
> > > extended.
> > 
> > Complete?  Try finding something that doesn't work.
> > 
> > > Meaning, how about an entry in changes and/or snippets?
> > 
> > Changes, regtests, snippets, documentation.  All that would be warranted and
> > required, turning this from a 60-line change to a 1000-line change, and
that's
> > before translations.  But that's not the main problem for me.  The main
> problem
> > is that the feature itself is straightforward and obvious, but examples and
> > descriptions are arbitrary and there are thousands of different ways to tell
> the
> > story.
> > 
> > And whatever way I pick is sure to be substantially rewritten anyway.  So
it's
> a
> > bit of a fight for me to muster the energy for the first shot at it.
> 
> So I guess a tracker for now would be good enough or should we wait some more?
> 
> James

Well, the absence of this feature tripped up a user who wrote code in the
expectation that it would work, and the feature very much works like other
similar features do.  His minimal example would have worked right out of the
box.  So I'd like not to hold this up unnecessarily.  But "regtests" don't
really count as unnecessary in any meaning of the book.  Even given a somewhat
tolerable overall track record.  So I'll add regtests to this issue, but I think
it's a reasonably good bet that I won't be knitting the behavior of \header into
the documentation in a convincing and timely manner.  So put up an issue for the
documentation.  I don't know yet whether this will need to include a Changes
entry or not: maybe I'll put one up as well if I get a good notion of one while
writing the regtests.

[thomasmorley651, 2016-06-28 20:10:00]

On 2016/06/28 17:29:19, dak wrote:
> On 2016/06/28 17:09:04, thomasmorley651 wrote:
> > Can't review the code.
> > From description: very nice.
> > 
> > Though, I'm not sure to which grade coding (with) header-expressions will be
> > extended.
> 
> Complete?  Try finding something that doesn't work.

Grabbed the code from here and did some testing.
From the experimental/empirical approach:
Looks _great_ to me!
Up to now I've not found a single bit of a disadvantage or limitation

> 
> > Meaning, how about an entry in changes and/or snippets?
> 
> Changes, regtests, snippets, documentation.  All that would be warranted and
> required, turning this from a 60-line change to a 1000-line change, and that's
> before translations.  But that's not the main problem for me.  The main
problem
> is that the feature itself is straightforward and obvious, but examples and
> descriptions are arbitrary and there are thousands of different ways to tell
the
> story.
> 
> And whatever way I pick is sure to be substantially rewritten anyway.  So it's
a
> bit of a fight for me to muster the energy for the first shot at it.

Most useful for the average user will be the now available possibility to store
a header in a variable.
I'd say at least this feature _needs_ an entry in changes.

[dak, 2016-06-29 16:58:47]

Changes entry, identifiers regtest

[thomasmorley651, 2016-06-29 21:56:23]

regtest and changes LGTM
From experimenting with it, changes in parser are great.

A remark, unrelated to current patch:

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
File input/regression/identifiers.ly (right):

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
input/regression/identifiers.ly:14: markupId = \markup { hoi }
markupId and stringId are not used later. Ofcourse this doesn't affect whats
tested here, but feels strange to me.
Change it while you're on it?

[Dan Eble, 2016-06-30 01:38:08]

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
File input/regression/identifiers.ly (right):

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
input/regression/identifiers.ly:11: scoreHeaderId = \header { piece = "Piece" }
This is a fantastic feature.

[dak, 2016-06-30 05:03:24]

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
File input/regression/identifiers.ly (right):

https://codereview.appspot.com/296600043/diff/20001/input/regression/identifi...
input/regression/identifiers.ly:14: markupId = \markup { hoi }
On 2016/06/29 21:56:23, thomasmorley651 wrote:
> markupId and stringId are not used later. Ofcourse this doesn't affect whats
> tested here, but feels strange to me.
> Change it while you're on it?

Oh.  Did not even notice that.

Acknowledged.

[dak, 2016-06-30 10:27:46]

Use \markupId and \stringId in identifiers regtest

[thomasmorley651, 2016-07-02 08:59:56]

LGTM