Re: ‘Bleed-over’ with LilyPond assignment to a Scheme value

[David Kastrup]

Simon Albrecht <address@hidden> writes:

> In a large project I ran into the following problem: If I define and
> call a function in Scheme-only syntax, \removeWithTag will ‘bleed
> over’ to following expressions (don’t ask me how exactly, I’m only
> guessing…).
> Consider the following dummy example:
>
> %%%%%%%%%%%%%%%%%%
> \version "2.19.35"
>
> test = { 1-\tag not-vl -"it works!" }
>
> #(define (build-part mus) (make-sequential-music (list mus)))
> % no problem with
> %#(define (build-part mus) #{ { $mus } #})
>
> vl =
> \removeWithTag not-vl
> #(build-part test)
> % no problem with
> %\build-part \test
>
> tbn =
> #(build-part test)
>
> \score {
>   \tbn
> }
> %%%%%%%%%%%%%%%%
>
> The TextScript should be displayed, but it isn’t. It works with either
> of the commented alternatives, i.e. those involving the LilyPond
> parser.  I’d be very much interested in the reason for this. It seems
> like an inconsistency that should be fixed.

Don't reuse music expressions in different contexts without _copying_
them.  $mus creates a copy.  \test creates a copy.  #test does not
create a copy.  Use ly:music-deep-copy or music-clone for getting the
equivalent of \test.  Many of LilyPond's music manipulating functions
are _destructive_ in order to allow for incremental manipulation of
large/growing music expressions.

There is no inconsistency.  Just a standard programming mistake.

-- 
David Kastrup