Re: Data structure for (package) options

[Urs Liska]

Am Dienstag, den 28.01.2020, 09:26 +0100 schrieb Han-Wen Nienhuys:
> On Mon, Jan 27, 2020 at 11:39 PM Urs Liska <address@hidden>
> wrote:
> > I didn't have time to really think about much (about LilyPond) the
> > past
> > week, just enjoyed seeing so much constructive discussion.
> > [..]
> 
> I haven't read your messages in detail, but I'd like to throw out one
> thought to consider: we use GUILE modules as a mechanism for
> identifier namespacing (\paper, \header all create modules). I think
> it might be useful if we could provide a LilyPond native mechanism
> for
> packaging that declares a namespace implicitly, 


That sound similar to what David suggested in 
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00349.html

> > Ok.  One thing to think about is that we want package files to be
> > contributed by "ordinary" users.  But something like
> >
> > \exportSymbols transposeSequence,instrumentGroup,scratchMyBack
> >
> > would be perfectly feasible syntactical sugar.

and following conversation on that thread.

I'm all for such an encapsulation strategy for packages.

> eg.
> 
>   \module "edition" {
>       internal = ...
>       addTweak  = ...
>   }

I think this concrete suggestion *looks* nice but would be awkward to
handle and impose restriction on how package authors can express
themselves.

I'd prefer (IISC more to David's suggestion) being able to write a
package as a regular .ly or .scm file with commands to explicitly
export/expose selected functions and variables.

> 
>   \import edition.addTweak

In analogy to Python one could have a choice between

  \import edition

for making all exported names visible or

  \import \with {
    addTweak.foo.bar
  } edition

for selectively importing three names.
(the \with being my current abuse of ly:context-mod?)

I have no strong opinion, and \import seems like a natural choice with
a programmer's eye, but \usepackage might be more expressive from a
document author's perspective.

> 
> that would let you define constructs in a package that doesn't
> pollute
> the global namespace, and let .ly packages control explicitly what
> symbols they want to use.
> 
> I think we should aim to avoid textual inclusion as a mechanism that
> powers packaging.
> 

That's a good point but will definitely be beyond what *I* can do.

Urs