Move Guile-style modules from scm to scm-modules

Move Guile-style modules from scm to scm-modules

As an initial step towards a package mechanism this patch
separates .scm files in /scm that are directly loaded with
ly:load from those that are explicitly loaded with
(use-modules (scm ...

The latter are moved to a new directory /scm-modules, and
the (use-modules clauses adjusted accordingly.





Load Scheme modules through scm-modules


Move Scheme modules to scm-modules

[mail5, 2020-01-29 12:20:10]

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

[dak, 2020-01-29 15:01:58]

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.

[mail5, 2020-01-29 15:14:32]

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

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.

> 

[hanwenn, 2020-01-30 08:52:28]

On Wed, Jan 29, 2020 at 4:02 PM <dak@gnu.org> wrote:
>
> 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

I agree with David here. Let's solve the hard problem first before we
care about cosmetics.


-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[dak, 2020-01-31 17:38:39]

Urs Liska <mail@ursliska.de> writes:

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

[幹你娘, 2021-08-11 06:55:37]

不得好死