Re: Data structure for (package) options

[Urs Liska]

Am Donnerstag, den 30.01.2020, 09:50 +0100 schrieb Han-Wen Nienhuys:
> On Tue, Jan 28, 2020 at 2:48 PM David Kastrup <address@hidden> 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