On 2012/09/30 08:33:16, marc wrote:
Am 30.09.2012 10:01, schrieb d...@gnu.org: > > http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm > File scm/bar-line.scm (right): > >
http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225
> > scm/bar-line.scm:225: (define-public bar-glyph-alist '()) > This interface definition is asking for trouble. It is an important > feature of LilyPond that if you use standard commands, their effects
to
> not bleed over from one run to the next. Information-carrying data > structures, for that reason, should be initialized in a .ly file
loaded
> from init.ly. Even then, the basic data structure should be one
that
> can be replaced by overwriting with a saved copy. That means that > hash-tables have to be either read/only, or start out as _empty_ in
a
> session (hash tables defined in the init.ly session get cleared at
the
> end of session IIRC). I am not sure if I understand you correctly.
Do you propose that the initialisation of the alists should be moved to ly/init.ly and that's it, more or less?
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. Consider _everything_ written in a .scm file as readonly conceptually. For an alist, you might want to define a _function_ returning the initial list, and the accessors should not be modifying it destructively (adding to the front of an alist does not change the original alist). Then you assign this initial value to a session variable in something included in init.ly, like #(define bar-glyph-alist (initial-bar-glyph-alist)) Your functions working with bar-glyph-alist have to take the version of bar-glyph-alist defined in the parser module. That means that when you call them from .ly files, you'll likely need to pass bar-glyph-alist from the .ly file into your Scheme function. Or get them via ly:parser-lookup via the parser variable. If you put a new bar line definition into a.ly, and when calling lilypond a.ly b.ly it is available in b.ly, then you have done something wrong. http://codereview.appspot.com/6498052/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
