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. For example, the following works in Guile 1.8 but not in Guile 2: (define (foo x) (bar x)) (define-macro (bar x) `(quote ,x)) In Guile 2, you must put the definition of 'bar' before 'foo'. So you'll need to load your code in the right order so that macros always come before their uses. 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. For example, the following is fine: (define-macro (beep x) `(boop ,x)) (define-macro (boop x) `(quote ,x)) That's because 'beep' doesn't use 'boop', it merely produces a use of 'boop' in its expansion. 'boop' is merely part of a quoted literal within 'beep'. Regards, Mark