Ian Hulin <i...@hulin.org.uk> 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.
> 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?
> However, I felt this was a potential maintainability swamp: the
> search-order could easily need changing again because some developer
> somewhere wanted to change one of the component modules, i.e. somebody
> could do a perfectly respectable and well-behaved change in Lily with
> Guile V1.8, and it would meanwhile blow up that version of lily.scm in
> Guile V2 without even knowing it.
Sure.
> So it seemed to me the neatest way of avoiding this was to make all
> the markup macros and procedures live in their own module, to be
> referenced via (use-modules (scm markup-facility-defs)) in the lily
> module, and then all the component *.scm files would have the markup
> definitions available when the (lily) module was being built, whatever
> position its source file occupied in the load list for ly:load in
> lily.scm.
How would that help? I don't see that one can avoid defining a macro
before use that way.
> I know you have another query about forcing the markup definitions
> into the (lily) module, but I'll talk about that in a separate post.
I don't think we can in good conscience assume that
a) a user can be expected to compile a Lilypond document into modules in
separate passes.
b) a user can be expected to never use variables in the lily module for
storing markups
It would appear to me that with the current problems you are reporting,
something like
foo=\markup { foo }
#(define-markup-command (zap layout props) ()
(interpret-markup layout props (markup foo)))
\markup\zap
would be unlikely to continue working. "define before use" is a policy
that we should, I suppose, be able to understand and implement. Once
Guilev2 is officially supported, making Patchy either try with both
Guilev1 or Guilev2 or at least use some additional compatibility
packages that enforce certain standards, would be doable.
The separate module stuff, however, appears to buy us not just scope
problems, but also seems to coincide with with multiple compilation
passes as well as mandatory declarations that are incomprehensible to
both developers as well as users.
If there is a choice in this, and so far I have not seen a compelling
argument against this, I would prefer going the route of proper
definition order. Inside of a user document, no-one will blame us for
that requirement or be particularly surprised or unable to understand or
cope. And inside of our own code base, I think we will be able to
manage.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
