Maybe I'm on the wrong track altogether, so I restart by stating more
generally what I want to achieve.
For Jan-Peter's lilypond-export package (the same can probably be
applied later to the export-targets of scholarLY annotations) export
functions for various formats are/will be implemented in separate modules.
Currently all available modules are loaded explicitly through
(use-modules) and the entry functions stored in an alist. Depending on
the requested export type the corresponding function is applied.
I want to change this to a more modular approach where the requested
export type acts as the key to an export module of the same type. So
something like
\exportMusic music #'musicxml
should locate and use the 'musicxml module and apply the function (say)
`export` from that module. Any new export format would then only have to
provide this `export` function to be "registered".
So the task at hand is to write a function that returns a specific
procedure from a Scheme module whose last element is specified by an
argument. (The leading path elements are fixed and the directory is in
the Scheme load path).
Urs
Am 29.10.2018 um 15:24 schrieb Urs Liska:
Am 29.10.2018 um 14:54 schrieb David Kastrup:
Urs Liska <[email protected]> writes:
Is there a way (well, I think I should ask: what's the way) to use
Scheme modules whose names are only available at runtime?
(use-modules (root-level my-module))
where my-module might change. What I actually want to achieve is load
all modules for which .scm files are found in a directory.
Alternatively is there a way to load all submodules of a given module?
https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Using-Guile-Modules.html#Using-Guile-Modules
doesn't seem to indicate any help, but I can't imagine there's no way
to load variable modules at runtime.
Any suggestions?
When all else fails, you can use primitive-eval to execute macro calls
you cobbled together dynamically.
Another approach would be to load the code with (load-from-path). But
IISC this *does* parse and provide the function(s) from the loaded
file but without the encapsulation provided by modules. So *all*
functions and variables defined in that file would be present from the
calling file, which isn't desirable.
Urs
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
