|
From: | Urs Liska |
Subject: | Re: Use a variable Scheme module |
Date: | Mon, 29 Oct 2018 15:37:51 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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 #'musicxmlshould 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 <address@hidden> 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-Modulesdoesn'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 address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-user
[Prev in Thread] | Current Thread | [Next in Thread] |