Re: Markup module patch (Issue 2026)

[David Kastrup]

Ian Hulin <address@hidden> writes:

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

Ok, I might be really bad at interpreting this, but I think the problems
might arise from trying to obey several identities for which I see no
compelling reason.

a) identity of files with compilation units.  You make it appear as if
every .scm file needed to get compiled into a separate .go file when it
would appear reasonable to just compile scm/lily.scm which includes all
the rest.

b) identity of compilation units with Scheme modules (in the namespace
sense).

If Guile v2 does not allow a compilation unit to be spread over more
than a single file, and/or requires macros from a separate file to be
loaded into a separate namespace, this would have appalling usability
consequences for Guile in general.

So either I interpret something wrong into what you are saying, or you
interpret something wrong into what the Guile developers are saying, or
the Guile developers interpret something wrong into what usability
should be saying.  Or a bit of each.

-- 
David Kastrup