lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Markup module patch (Issue 2026)


From: Ian Hulin
Subject: Re: Markup module patch (Issue 2026)
Date: Sun, 18 Dec 2011 11:46:40 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0

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.
> 
>> When Patrick M. first tried out using Lily with Guile 2, the only
>> way we could use it was by relying on the equivalent of the
>> Guile --auto-compile option.
> 
> What do you mean with "equivalent"?  In Guilev1, it is not even
> defined.
> 
(See previous reply in the thread).
>> During initialization on the first pass through lily.scm, when
>> we're building the (lily) module, we got an awful lot of barfs
>> from Guile that various things, almost always from the markup
>> stuff were unbound variables.
> 
> 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.

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.

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.

My current plan for 1686 is to retain this way of building all the
(lily) definitions, but pre-compile the component scm/*.scm files and
load the resulting scm/out/*.go files.  Ideally I want to generate
these during the build using Guile V2 'guild compile', but I'm
prototyping at the moment with extra hooks in our custom load routine
to compile on-the-fly in the ly:load procedure in lily.scm.

Again, I'll answer your other enquiries in separate posts.

Cheers,

Ian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]