Mark H Weaver <[email protected]> writes:
> David Kastrup <[email protected]> writes:
>
>> Mark H Weaver <[email protected]> writes:
>>
>>> David Kastrup <[email protected]> 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.
Because the individual files are not independent from one another?
That's why I wrote:
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.
--
David Kastrup
