Re: markup commands leaks (Re: Scheme question on strict substitution)

[Han-Wen Nienhuys]

Nicolas Sceaux escreveu:
> Han-Wen Nienhuys <address@hidden> writes:
> 
>> Nicolas Sceaux escreveu:
>>>> [Issue 162]
>>>> Yes, but this introduces a new problem. Putting stuff into lily module
>>>> from a .ly file means that definitions from one .ly file will leak
>>>> into another, which is also a problem.
>>> I don't understand: what leaks into what?
>> if you do 
>>
>>   lilypond file1.ly file2.ly
>>
>> then if file1 modifies the (lily) module ,  this will also affect how 
>> file2 is processed. Of course, the order of processing should not affect
>> the end result.  
> 
> Defining the markups in a markup-init.ly file triggers some issues. Some
> .scm files loaded from lily.scm use make-COMMAND-markup functions. So
> the built-in markup commands need to be defined or imported in the
> (lily) module.

> One solution could be to make the make-command-markup macro define the
> commands in the (lily) module when it is called from it (ie in the
> define-markup-commands.scm file loaded from lily.scm), but when it is
> called from a user .ly file, define the commands in an other module.
>
> This could be a (user-markup) module, #:used by the anonymous modules
> created when parsing a .ly file. That (user-markup) module would be
> cleaned between two main ly file processing --I don't know yet how--
> to avoid the side-effects.

I think this is not a good idea, as we'd have to import (user-markup)
separately in each newly created anonymous module; that would require
a strange tieing of ly_make_anonymous_module() with the language
specifics.
 
I think it would be better if we redefine the builtin markup commands
in the toplevel .ly module as in

markup-init.ly:

 #(for-each 
    (lambda (command)
     (module-define! (current-module)  
                     (markup-command-name command)
                     (markup-command-function command))
     ..copy make-XXXX-too..                  
                     )
    builtin-markup-commands) 

Since nested scopes import the toplevel scope automatically, this
should work.

Of course, the built-in markups could come from a (scm builtin-markup)
module. That's even to be preferred, as the namespace is too large
anyway.
    

-- 

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com