Re: Autocompilation/LilyPond

[Mark H Weaver]

David Kastrup <address@hidden> writes:

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

Excellent!  As long as you load everything in the right order, such that
macros are defined before they are used, I don't see why there should be
any other problems related to macros and compilation.

     Mark