Am Dienstag, den 28.01.2020, 09:26 +0100 schrieb Han-Wen Nienhuys: > On Mon, Jan 27, 2020 at 11:39 PM Urs Liska <li...@openlilylib.org> > 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