[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