On Tue, Jan 28, 2020 at 2:48 PM David Kastrup <d...@gnu.org> 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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
