Re: Data structure for (package) options

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> 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, eg.
>
>   \module "edition" {
>       internal = ...
>       addTweak  = ...
>   }
>
>   \import edition.addTweak
>
> 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.

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.

It's likely that a typical more complex package may consist of both .ly
and/or .scm components and that is an implementation detail that a
package user should not need to bother about, and that hopefully should
not significantly complicate things for people wanting to provide
packages with either or both .ly and/or .scm components.

-- 
David Kastrup