Am Donnerstag, den 30.01.2020, 09:50 +0100 schrieb Han-Wen Nienhuys: > On Tue, Jan 28, 2020 at 2:48 PM David Kastrup <d...@gnu.org> wrote: > > > > I think we should aim to avoid textual inclusion as a mechanism > > > that > > > powers packaging. > > > > At the implementation side, "textual inclusion" will be what has to > > power systems where one can "plug in" packages and have them work > > by > > being present. Even Guile's use-modules mechanism works at that > > level. > > But of course that doesn't mean that we want \include as a user- > > level > > access method in the long haul. > > By textual inclusion, I mean a mechanism that must insert all its > data > in the global namespace. Library systems usually must have means to > be > explicit about external APIs and internal implementation details. I > am > advocating that there is an easy to use mechanism such that OLL > packages can shield some of the implementation from other packages. >
My idea for packages is: * packages *always* have .ly files as entry points (even if their "real" work is exclusively Scheme). That makes it easier to handle (no need to load packages in two different forms) and gives regular users a lower threshold of moving library code to packages. * they explicitly define their public interface. See below for my ideas about that. * A new command \usepackage will either load the whole package or only a subset of its interface (like the "from X load Y" syntax in Python). Maybe a clean way of making an interface explicit would be not to do myFunction = #(define-music-function ... but having a new (set of?) command(s) that allow \export myFunction #(define-music-function When parsing the package (i.e. loading it for the first time `myFunction` is stored as the package's interface (in an internal structure storing the interfaces of all loaded packages, along with their defined options). [This is something *I* can do with the current Scheme possibilities] When using a package that has already been loaded (\usepackage checks that first) the stored Scheme values (which may equally be variables or procedures) are made visible in the caller's scope. The question I have is: If \usepackage makes the names available to everything else later (like a regular \include of a LilyPond file) I can do this with what we already have in Scheme. If \usepackage should make the names available only within the current input file (like (use-modules) does) I think \usepackage would have to be implemented at the parser level. Urs