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. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
