[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: What's the deal with the module system?
Date: Tue, 24 Nov 2009 11:28:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

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 e.g. redefines a builtin command, it shall not change the
>> behavior of other file compilation:
>>   lilypond
>> shall give the same result as:
>>   lilypond
>>   lilypond
>> Corollary: a command defined in, shall not be accessible from 
>> in the "lilypond" 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:
#(define-public xxx "Hello")
#(display xxx)
#(export xxx)
#(display xxx)

Running delivers:

GNU LilyPond 2.13.8
Processing `'
Parsing...Hello warning: no \version statement found, please add

\version "2.13.8"

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

\version "2.13.8"

for future compatibility
error: failed files: ""

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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]