Re: Iterating music for voiceOne. Checking with equal?

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Thomas Morley <address@hidden> writes:
>>
>>> Hi,
>>>
>>> I stumbled across
>>> (equal?  #{ \voiceOne #} voiceOne)
>>> returning false.
>>>
>>> Is it expected behaviour?
>>
>> equal? is not implemented all that great for "probs" but Music::equal_p
>> is implemented in a manner where at least
>>
>> #(display (equal? voiceOne (ly:music-deep-copy voiceOne)))
>>
>> would be expected to display #t and it doesn't.
>>
>> Sigh.  I'll see what I can find out.
>
> Tracker issue: 5391 (https://sourceforge.net/p/testlilyissues/issues/5391/)
> Rietveld issue: 363740043 (https://codereview.appspot.com/363740043)
> Issue description:
>   Prob::equal_p: discard "origin" property  Previously elements of
>   class Input was considered equal when compared as part of Music
>   property lists but this did not take into account that some music
>   might store its origin (if any) at different locations in its
>   property lists.  So we just discard any "origin" property
>   completely, regardless of position in the property list and its
>   actual value type.   Also contains commit:  Don't set origin on
>   copied music explicitly  There would be some mild incentive if the
>   origin were accessed an inordinary amount of times (and thus leaving
>   it unset would maximize access times to it) but there is no evidence
>   for that.  One reason might be to ensure greater structural
>   similarity between copies of music, but Prob::equal_p has been
>   changed to be robust against differences here.

In the mean time, here is a workaround:

voiceOne = \voiceOne

Seriously.

-- 
David Kastrup