Re: Scoping of Guile modules

[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/

> Are you trying to create a setup where the byte-compiled files are
> preinstalled?

I'm not sure what you mean by "pre"installed. But yes, from what I can
see we will need to get compiled bytecode to reach startup times and
overall performance comparable to Guile 1.8. I intend to post exact
numbers once I have a complete setup, but it looks like having all .scm
files compiled into .go files (currently via GUILE_AUTO_COMPILE) gets
most metrics on par with Guile 1.8...

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