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

[David Kastrup]

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.

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

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 markup-init.ly 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 markup-init.ly 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