Re: Use a variable Scheme module

[Urs Liska]

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 <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-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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user