Mark H Weaver <m...@netris.org> writes: > David Kastrup <d...@gnu.org> writes: > >> with the stable release 2.16 of LilyPond looming around the corner, it >> will become imminent soon to think about supporting Guile 2.0. >> >> Previous attempts have mostly exploded around the problem that we have >> something like >> >> (for-each ly:load init-scheme-files) >> >> in our lily.scm file, and the auto-compiler attempts to compile all >> of those files independently as far as I understand. Unfortunately, >> some of them contain macro definitions that other files rely on. >> >> Personally, I think it would make sense if we could get the >> autocompiler to treat the whole blob of files as _one_ unit, and >> recompile the unit if it gets out of date. > > I'm not sure that would help much. There's a deeper problem that you > should be aware of. In Guile 1.x, macro uses within procedures are > not expanded until the procedure is evaluated. In Guile 2, macros are > expanded as soon as the procedure is defined, even if compilation is > turned off. This means that functions can only use macros that were > previously defined.
I don't think that making this condition hold would be really hard. LilyPond has a rather carefully selected load order in several stages, so use-before-definition, whether in the context of macros or not, should be more the exception than the rule, and only require smaller rearrangements. > One clarification is in order. You might conclude from this that it > is not possible to define mutually-recursive macros, but that's not > true. I don't think we use them, anyway. Most problems are more due to small oversights rather than maliciously clever overdesign. -- David Kastrup
