Re: Scoping of Guile modules

[Jonas Hahnfeld]

Am Samstag, dem 06.02.2021 um 22:27 +0100 schrieb Jonas Hahnfeld:
> Am Samstag, dem 06.02.2021 um 21:01 +0100 schrieb Han-Wen Nienhuys:
> > On Sat, Feb 6, 2021 at 7:21 PM Jonas Hahnfeld <hahnjo@hahnjo.de>
> > wrote:
> > > While trying to understand the current situation of LilyPond and its
> > > Guile modules, I noticed that there is a certain split:
> > >  * lily.scm and all files pulled in by ly:load are referenced relative
> > > to scm/, ie just the file name (without the extension after my changes
> > > at https://gitlab.com/lilypond/lilypond/-/merge_requests/635 ).
> > >  * On the other hand, proper modules are prefixed with (scm), for
> > > example (scm framework-ps) and (scm output-ps).
> > > 
> > > This works right now, but requires that main_with_guile prepends both
> > > the determined datadir and datadir + "/scm" to the %load-path. Similar
> > > treatment would be necessary for %load-compiled-path for the compiled
> > > bytecode. That's a bit ugly because it requires an scm/ directory to
> > > hold the compiled .go files...
> > > 
> > > I experimented with this locally and it seems possible to remove the
> > > (scm) scope and reference all modules relative to scm/, ie have modules
> > > (framework-ps), (output-ps) and so on. My question would be: Is there a
> > > good reason *not* to do this?
> > > As far as I could find out, this split goes back to the very first
> > > module added in commit
> > > https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b
> > > from 2001. I'm adding Han-Wen and Jan, do you happen to remember if
> > > that was an explicit choice or "just worked"?
> > 
> > I think this is a setup that stuck to the wall when we threw it, so
> > there is no urgent reason to keep the naming precisely like this.
> > However, other Scheme modules are grouped (eg, "(srfi srfi-1)" or
> > "(ice-9 optargs)"). I think it would be good to follow this style and
> > have a lilypond-specific prefix. Maybe "(lily framework-ps)" ?
> 
> Yes, that would have been my next question: We can either go with a
> flat layout like (framework-ps) or introduce our own scope that we use
> consistently, like (lily framework-ps). Upon installation that would
> require a subdirectory to both scm/ and the directory holding the
> compiled bytecode, certainly doable I would say. What I'm not sure
> about is lily.scm that is loaded into a module (lily) created by
> lily/guile-init.cc. Should this become (lily lily), which looks odd, or
> can this stay (lily) and still have submodules? Note that keeping this
> at (lily) might be slightly awkward because it means that lily.scm must
> not be installed in scm/lily/ like all other files, but only scm/

This is now https://gitlab.com/lilypond/lilypond/-/merge_requests/710
(at least for the sources, nothing related to bytecode yet).

signature.asc
Description: This is a digitally signed message part