Thomas Morley <thomasmorle...@googlemail.com> writes: > 2012/9/30 <d...@gnu.org>: >> On 2012/09/30 19:44:49, marc wrote: >>> >>> Am 30.09.2012 11:02, schrieb d...@gnu.org: >>> > [...] >>> > 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel