Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2012/9/30  <address@hidden>:
>> On 2012/09/30 19:44:49, marc wrote:
>>>
>>> Am 30.09.2012 11:02, schrieb address@hidden:
>>> > [...]
>>> > First, the define-public is asking for trouble. You are exposing an
>>> > internal Scheme data structure to users and make it overwritable by
>>
>> the
>>>
>>> > user. If the user follows this invitation, the effects will bleed
>>
>> over
>>>
>>> > from session to session. Never do that.
>>> Ok.
>>
>>
>> No, it's not ok.  Hold your horses, this is another case too stupid for
>> documenting and walking people through.  Give me two days, and then you
>> replace your define-public for the alists with define-session, and
>> that's it.  The rest of the code stays as it is.
>>
>> I'll make define-session do everything that is needed.
>>
>
> That would be very nice.
> I can think of several functions/definitions currently destructively
> changing internal Scheme data structures.
> Perhaps they would work as expected then.

See <URL:http://code.google.com/p/lilypond/issues/detail?id=2872>.  The
session management does not do any structure copying, so any
_modification_ of structures is not going to be restored.  The value of
the variables defined with (define-session ...) itself, however, will
get restored, so as long as you "modify" your alists only by prepending
elements, or do a copy-and-modify yourself (leaving the original
structure intact), this should work out.  It would be feasible to do
copying, but then one needs to use a different copying method for a
variety of types, and copy for creating the initial session values, and
copy for replacing them.  I wanted to avoid that overhead.

-- 
David Kastrup