Re: What's the deal with the module system?

[David Kastrup]

David Kastrup <address@hidden> writes:

> Nicolas Sceaux <address@hidden> writes:
>
>> Please ignore this case, it's broken. What I had in mind a bit more
>> complex, and probably does not really matter.
>>
>> The two important points to keep in mind are:
>>
>> 1) user defined commands shall not pollute the internal modules
>> When file1.ly e.g. redefines a builtin command, it shall not change the
>> behavior of other file compilation:
>>   lilypond file1.ly file2.ly
>> shall give the same result as:
>>   lilypond file1.ly
>>   lilypond file2.ly
>> Corollary: a command defined in file1.ly, shall not be accessible from 
>> file2.ly
>> in the "lilypond file1.ly file2.ly" case. No side effect allowed.
>
> I don't see how you can achieve this reliably without redefining all of
> the core's *-public commands as well as export.  If you do that,
> however, it is trivial to use the same code for *-builtin-* and the user
> level equivalents: compile those with a version of the redefined core
> commands that can switch its target module for public definitions to the
> user "toplevel" but has it set to the system toplevel during execution
> of the, well, public scheme files.
>
> *-public commands in modules will also have to be covered, which makes
> this approach sort an open-ended task.  However, I think that few
> modules actually provide *-public defining commands, so this might sound
> worse than it is.  Absolute security will not be possible in this manner
> since new guile releases might come with new *-public commands.

Cough, cough.  I actually tried the following:
test1.ly:
#(define-public xxx "Hello")
#(display xxx)
#(export xxx)

test2.ly:
#(display xxx)

Running delivers:

lilypond test1.ly test2.ly
GNU LilyPond 2.13.8
Processing `test1.ly'
Parsing...Hello
test1.ly:0: warning: no \version statement found, please add

\version "2.13.8"

for future compatibility
Processing `test2.ly'
Parsing...
test2.ly:1:1: error: GUILE signaled an error for the expression beginning here
#
 (display xxx)
Unbound variable: xxx
test2.ly:0: warning: no \version statement found, please add

\version "2.13.8"

for future compatibility
error: failed files: "test2.ly"
address@hidden:/tmp$ 

So it would appear that the public defining commands already don't
export not further than toplevel, probably because exports more or less
just "throw" their value upwards to the module having issued the
corresponding "usemodule" but not further.

This is pure speculation on my part.  Whatever the mechanism, it would
appear that the necessary encapsulation for define-public is already in
place.

-- 
David Kastrup