Re: What should the relation between \book / \bookpart be?

David Kastrup <[email protected]> writes:

> I am currently working on books, and with regard to what books and
> bookparts contain, there is almost no structural difference (a bookpart
> may even contain a paper block using, for example, different page break
> algorithms to the rest of the book).
>
> Right now, most of the functionality is determined ad-hoc which is why
> you cannot really write something like
>
> bookA = \book { ... }
>
> \bookA
>
> but have to write
>
> \bookA = \book { ... }
>
> \book { \bookA }
>
> instead.  Similar with scheme functions returning a book: they cannot be
> used at top level.
>
> So there is a case for not distinguishing them at all in structure and
> always require an enclosing \book / \bookpart block for any use outside
> of assignments.  Which is more or less what we have now.
>
> That saves us from having to distinguish between
>
> bookA = \book { ... }
> bookB = \bookpart { ... }
>
> \book { \bookA ... }
>
> which would mean to create a book as an amended copy of \bookA and
>
> \book { \bookB }
>
> which would mean to create a book containing \bookB as a bookpart.
>
> I am not sure whether our current implementation is perfectly agnostic
> in that regard.
>
> So there is some incentive to be able to use either as either.  However,
> there is one complication: a book _can_ contain bookparts (but does not
> need to).  A bookpart can't.
>
> If one would use a book already having bookparts as a bookpart, it would
> need to shed its own bookparts.
>
> The other possibility is to nail down the distinction book/bookpart in
> the type/structure.  Either as a default when not explicitly recast, or
> hardwired.
>
> Problem either way is that the ability not to specify one's wanted
> manner of use makes something like
>
> \book { \bookpartA ...
>
> ambiguous: are we recasting \bookpartA into a book type and amending the
> resulting book, or are we creating a book from scratch containing
> \bookpartA as its first bookpart?
>
> For rearranging an existing source into something that is only a part of
> a larger document, the current relative fluidity between book and
> bookpart may be convenient.
>
> On the other hand, expectations are likely that whether something is a
> \book/bookpart is more ingrained.
>
> Where to go?

To add a few more reference points: as of year 2008, apparently
bookparts can be nested lexically, using a '$paper' variable to keep
track of the recursion.

commit bac26647e4febc81786565b02468f122c5a26b11
Author: Nicolas Sceaux <[email protected]>
Date:   Sun Nov 16 20:45:37 2008 +0100

    Nested bookparts: fix $papers pop in case of \book block with identifier

The syntax, however, does not permit any nesting other than putting a
bookpart inside of a book.  That threat appears to be a red herring
_lexically_.  However, nobody stops you from saying

xxx = \book { \bookpart { \score c } }
\book { \bookpart { \xxx } }

because a book identifier is a book identifier.

Then there is the following

commit 19625d063f3c3a9cf005966284e5aa055c8767e2
Author: David Kastrup <[email protected]>
Date:   Sat Dec 14 22:33:53 2013 +0100

    Issue 3728: Allow score and book identifiers at top level, and score identifiers in book(part)s
    
    Instead of
    
    xxx = \score { ... }
    yyy = \book { ... }
    \score { \xxx }
    \book { \yyy }
    
    you can now just write
    
    xxx = \score { ... }
    yyy = \book { ... }
    \xxx
    \yyy
    
    Book and bookparts at top level are distinguished by virtue of only
    books having a \paper block.

which falsely relies on bookparts and books being distinguished reliably
by paper blocks.  They aren't.

Then in spite of purportedly bookparts being nestable (though the
current syntax does not cater for it) we have toplevel-bookpart-handler,
book-bookpart-handler, but no bookpart-bookpart-handler.

Then there is the following:

commit 86994e0b5758ff44bd81c74ac49127076562885b
Author: David Kastrup <[email protected]>
Date:   Thu Feb 23 19:19:37 2012 +0100

    Issue 2343: Faulty file-naming when outputting multiple \books

which introduces and abuses an absurd catch-all function called
"paper-variable" which actually isn't about paper variables and just
screams "I want credit for stamping out a problem terminally but have no
clue what I am actually doing".

You get the drift.

I see three possibilities: a book or bookpart gets stamped at creation
for being one or the other depending on whether it is done using \book
or \bookpart.  This is sticky and determines the allowable use.

Possibility 2: the same, but identity is lax, and explicit use can
override the stickiness.  But then what does

xxx = \bookpart { }

\book { \xxx ...

mean?  A book started as copy of \xxx or a book containing a bookpart
\xxx ?

Possibility 3: there is only one data type, and only its syntactic use
determines which of the two it will be.

You cannot write

xxx = \book { ... }
\xxx


-- 
David Kastrup