Urs Liska <m...@ursliska.de> writes: > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: >> On 2020/01/29 12:20:10, mail5 wrote: >> > Unfortunately I haven't set up a build system on my new computer >> > yet, >> so this >> > patch is not tested locally at all, so I'm humbly waiting for the >> automated >> > tests to succeed or fail ... >> >> I don't like the "use-modules clauses adjusted accordingly". I don't >> think it makes sense readjusting use-modules clauses all the time >> while >> we are deciding on the final module organisation, so I'd strongly >> suggest first biting the bullet and deciding on a syntax for a >> user-level command able to load Scheme modules without further >> options, >> and then introduce that command. In that manner, future directory >> organisations (which are almost certain to come) will not affect the >> source of user-level documents any more. >> >> https://codereview.appspot.com/567140045/ > > Maybe I'm missing something, but AFAICS there will always be the need > for a module path like (ice-9 regex), or (scm display-lily). We will > have that with *any* user-facing load syntax.
\loadScmPackage display-lily or even \loadPackage display-lily.scm with the last .scm getting interpreted specially. #(use-modules ...) is not a user-facing load syntax. We don't want people to have to change their input when an optional package migrates to the system or a local package changes hierarchy. Specific path components may make sense for disambiguation, but if I take a look at what LaTeX does, a flat hierarchy as first user-level approximation does not appear to have significant scaling problems. > > My thought was to separate the two different types of .scm files in > that directory, and that could of course also be achieved by moving the > *other* files, those that are loaded with ly:load from lily.scm to a > different directory. > > Or - of course - I can simply drop this and add new modules to that > same directory for now. > >> > > > -- David Kastrup