Re: Autocompilation/LilyPond

[Mark H Weaver]

David Kastrup <address@hidden> 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