Re: Fwd: Custom accidental styles

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Dan Eble <address@hidden> 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