David Kastrup <[email protected]> writes: > David Kastrup <[email protected]> writes: > >> Dan Eble <[email protected]> writes: >> >>> From the Guile docs: >>> >>> `define' (when it occurs at top level), `scm_define' and >>> `scm_c_define' all create or set the value of a variable in the top >>> level environment of the current module. If there was not already a >>> variable with the specified name belonging to the current module, but a >>> similarly named variable from another module was visible through having >>> been imported, the newly created variable in the current module will >>> shadow the imported variable, such that the imported variable is no >>> longer visible. >>> >>> So for >>> >>> xxx.yyy = ... >>> >>> we quite likely want set! semantics. How about for >>> >>> xxx = ... >>> >>> ? >> >> Ugh. >> >> GNU LilyPond 2.19.43 >> Processing `input/regression/collision-2.ly' >> Parsing.../usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: >> In expression (break pred lst): >> /usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: >> Wrong type to apply: #<Prob: Music C++: Music((origin . #<location >> /usr/local/tmp/lilypond/out/share/lilypond/current/ly/declarations-init.ly:64:9>) >> (break-permission . force))((display-methods #<procedure #f (expr)>) >> (name . LineBreakEvent) (types line-break-event break-event event)) > >> >> `break' is a procedure (automatically loaded) in (srfi srfi-1). It is >> also a music expression in ly/declarations-init.ly. >> >> Overwriting it does not seem like a good idea... > > So the question is what to do with partial list assignments. The > assumption would likely be that the user _knows_ he wants to modify an > existing list in its own module when not writing xxx = #'() before > assigning to xxx.yyy. > > But I'm queasy about that. It could result in spacing settings in some > \header or \layout to have more global effects than intended.
Ok, just pinned this down by changing session-define-public. Tracker issue: 4858 (https://sourceforge.net/p/testlilyissues/issues/4858/) Rietveld issue: 300110043 (https://codereview.appspot.com/300110043) Issue description: Let define-session-public place variables natively into parser Putting them as native variables in the parser module (rather than using export/import) makes `set!' and `define' equivalent rather than having `define' create a shadowing definition of the session variable. That is important in order to avoid the values of the variable diverging between parser module and `lily'. Your example works fine with that change. It should also allow foregoing the use of ly:parser-lookup/ly:parser-define! in a number of cases since session-export variables are now automatically shared between `lily' module and parser. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
