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

[David Kastrup]

Simon Albrecht <address@hidden> writes:

> On 18.01.2016 17:32, David Kastrup wrote:
>> 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.
>
> 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