lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by


From: David Kastrup
Subject: Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by address@hidden)
Date: Fri, 31 Jan 2020 18:38:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb address@hidden:
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]