Ian Hulin <i...@hulin.org.uk> writes: > This is to allow an attempt at separation of function so we don't have > to have every single scheme-level procedure defined in the body of > lily.scm itself. However the vast majority of these scheme files just > get loaded and evaluated and the scheme procedures are added to the > (lily) module. > > The difference in behaviour here between the two Guile flavours is > Guile V1.8 is less fussy because it allows a level of lazy binding, > which means may get away with forward referencing a macro until the > component scheme file is subsequently loaded and defines the macro. > Guile V2 won't stand for this at all. > > My current plan for 1686 is to retain this way of building all the > (lily) definitions, but pre-compile the component scm/*.scm files and > load the resulting scm/out/*.go files. Ideally I want to generate > these during the build using Guile V2 'guild compile', but I'm > prototyping at the moment with extra hooks in our custom load routine > to compile on-the-fly in the ly:load procedure in lily.scm.
Ok, I might be really bad at interpreting this, but I think the problems might arise from trying to obey several identities for which I see no compelling reason. a) identity of files with compilation units. You make it appear as if every .scm file needed to get compiled into a separate .go file when it would appear reasonable to just compile scm/lily.scm which includes all the rest. b) identity of compilation units with Scheme modules (in the namespace sense). If Guile v2 does not allow a compilation unit to be spread over more than a single file, and/or requires macros from a separate file to be loaded into a separate namespace, this would have appalling usability consequences for Guile in general. So either I interpret something wrong into what you are saying, or you interpret something wrong into what the Guile developers are saying, or the Guile developers interpret something wrong into what usability should be saying. Or a bit of each. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
