Simon Albrecht <[email protected]> writes: > On 18.01.2016 17:32, David Kastrup wrote: >> Simon Albrecht <[email protected]> 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. > > Well, such will happen if one has never decently learned programming, > such as me… > > Sorry for the noise, and thanks for the explanation.
Well, it's a design decision of LilyPond. For functions like \transpose or \relative it would be rather wasteful to create a copy each time when it is likely the only use anyway. However, music variables might be used several times because of having a name, so using them in the standard manner creates a copy. When writing music functions, make sure that you either use each input argument only once or make a copy for every use (important: _every_ use without exception unless you know for sure that any modifications of the non-copied version will happen _after_ all other copies have been created). That's one of the most frequent recipes for trouble when working with Scheme code. However, the alternative would be for many functions to create complete copies rather than work in-place. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
