[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 10:54:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

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.

But I don't think that security is really not as much a target here as

This approach allows the current code of the *-builtin-* defining
commands to be used for the user variants as well.

Doing it the other way round also is a possibility.  In that case,
moving most of to public scheme files and just
duplicating the
#(let ((toplevel-module (current-module)))
   (set! toplevel-module-define-public!
         (lambda (symbol value)
           (module-define! toplevel-module symbol value)
           (module-export! toplevel-module (list symbol))))
   (set! toplevel-module-ref
         (lambda (symbol)
           (module-ref toplevel-module symbol))))

sequence into both as well as the top of the first loaded
public code scheme file should do the trick.  In this case the
*-toplevel commands will, while loading the system files, actually
define their stuff in global scope.

This offers less "security", but not less than what we currently have,
and more transparency.  However, it will mean that users using *-public
commands will cause permanent effects, possibly unwittingly.

> 2) A user command defined in one included file shall be accessible
> from another included file.

The above approach would give that.  I am not saying that it is the best
possible approach.

David Kastrup

reply via email to

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