Re: Data structure for (package) options

[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.

> 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



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen