lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: dak
Subject: Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Date: Sun, 30 Sep 2012 09:02:48 +0000

On 2012/09/30 08:33:16, marc wrote:
Am 30.09.2012 10:01, schrieb address@hidden:
>
> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]