Am 07.11.2014 12:31, schrieb David Kastrup:
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.
OK, if I really understand that it would perfectly match my idea of
conditional loading (although through a different path).
> What we need is to drag the concept of modules into LilyPond,
What do you mean by this?
Do you suggest to implement a module approach that is somewhat parallel
to Scheme's use-module approach?
Or rather try to "package" a module approach in Scheme modules somehow?
My impression is that defining and loading modules should be simpler
than defining (and to some extent using) Scheme modules. At least there
should be some syntactic sugar so one can use a "\" command to import a
library.
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
