Re: Markup module patch (Issue 2026)

[David Kastrup]

Ian Hulin <address@hidden> writes:

> Hi David,
> On 16/12/11 17:51, David Kastrup wrote:
>> Ian Hulin <address@hidden> writes:
>> 
>>> Guile V2 insists on some thing, particularly macros being
>>> defined before they are used.
>> 
>> That's not unreasonable.

[...]

>> Why do we need to "build the lily module"?  What advantages does
>> it have?
>> 
> That's the way it's done.  The code in main.cc boots up guile with
> scm_boot_guile with main_with_guile (in main.cc) as a callback.  This
> calls ly_c_init_guile (in guile_init.cc) which calls ly_init_ly_module
> (also in guile_init.cc).  This declares the (lily) module, and loads
> scm/lily.scm via scm_primitive_load_path.
>
> Now lily.scm builds the (lily) module by loading in a whole list of
> scheme files in the scm/ directory.

That's not "building the lily module" as much as it is just loading
Lilypond.  Of course every definition ends up in some module.

> This is to allow an attempt at separation of function so we don't have
> to have every single scheme-level procedure defined in the body of
> lily.scm itself.  However the vast majority of these scheme files just
> get loaded and evaluated and the scheme procedures are added to the
> (lily) module.

Sure.

> The difference in behaviour here between the two Guile flavours is
> Guile V1.8 is less fussy because it allows a level of lazy binding,
> which means may get away with forward referencing a macro until the
> component scheme file is subsequently loaded and defines the macro.
> Guile V2 won't stand for this at all.

So we cater for a load and definition order where every macro is defined
before it gets used.  Where is the problem with that?

It is a one-time effort.  And it will cause no particular surprises to
users of LilyPond.

In contrast, having to do separate passes for macro definitions and
other definitions with different modules where stuff ends up, not just
for our own code but apparently also for user-level definitions, is
going to end up a permanent fragile and hard to understand maintenance
nightmare.  Not just for the developers, but also for its users.

Users don't want to get exposed to the effects of module switching and
multi-passes.  Come to think of it, neither want developers.

-- 
David Kastrup