Re: Autocompilation/LilyPond

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> 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.

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