Urs Liska <u...@openlilylib.org> writes:
> \import harmonic-analysis
> would load everything at once (I'd even suggest this command working
> with symbolic names and not filenames).
>
> \importFrom harmonic-analysis #'(pitch-class riemann)
> would only load the two submodules.
> (The submodule would have to \import the main module if it depends on
> code in it).
>
> What do you think?
The latter is a complication we can do without in my book. What we need
is to drag the concept of modules into LilyPond, and those mostly
determine name spaces rather than loaded files. I don't think we need
submodules: the GUILE module system allows autoloading files
conditionally when a symbol gets referenced:
-- syntax: define-module module-name option …
MODULE-NAME is a list of one or more symbols.
(define-module (ice-9 popen))
‘define-module’ makes this module available to Guile programs under
the given MODULE-NAME.
OPTION … are keyword/value pairs which specify more about the
defined module. The recognized options and their meaning are shown
in the following table.
‘#:use-module INTERFACE-SPECIFICATION’
Equivalent to a ‘(use-modules INTERFACE-SPECIFICATION)’ (*note
Using Guile Modules::).
‘#:autoload MODULE SYMBOL-LIST’
Load MODULE when any of SYMBOL-LIST are accessed. For
example,
(define-module (my mod)
#:autoload (srfi srfi-1) (partition delete-duplicates))
...
(if something
(set! foo (delete-duplicates ...)))
When a module is autoloaded, all its bindings become
available. SYMBOL-LIST is just those that will first trigger
the load.
An autoload is a good way to put off loading a big module
until it’s really needed, for instance for faster startup or
if it will only be needed in certain circumstances.
‘@’ can do a similar thing (*note Using Guile Modules::), but
in that case an ‘@’ form must be written every time a binding
from the module is used.
[...]
So loading the module should just imply providing all the interfaces and
functions. Loading the actual code can be done on-demand in case some
library covers more obscore use cases in separate files.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
