Re: T1349 - Fix load order for running with Guile V2 (issue 4849054)

[Patrick McCarty]

On Thu, Aug 18, 2011 at 3:30 AM, Ian Hulin <address@hidden> wrote:
> On Thu 18 Aug 2011 07:50:28 BST, address@hidden wrote:
>
> The load-order issue appears to be fixed, testing with git and guile 1.8
> and 2.0.2. Ignoring whitespace changes, this patch LGTM.
>
> Some more shuffling is needed to make sure we have markup commands
> defined where they need to be, but that's beyond the scope of this
> patch.
>
> Should we have a Lilypond Markup Syntax/Guile V2 Tracker, then?

I think we should have one tracker per issue that we encounter.  It
becomes difficult to handle what has been fixed (and where) when we
have umbrella issues.

> If there are any dependencies in the load list that you know about that can
> still bite us could we record these in the tracker, for instance the markup
> command itself works with both Guile 1.8 and 2.0 if it is loaded later in
> the list in a module apart from markup-macros.scm, but fails with 2.0 if you
> move the definition from markup.scm to the bottom of markup-macros.scm.

Yes, any issues we find like this should have separate tracker issues.
 I've just opened one:

https://code.google.com/p/lilypond/issues/detail?id=1826

I'll open more later today if I find time.

> There are also some design issues to consider like:
>
> Would the markup.scm and markup-macros.scm definitions work better as a SCM
> module?

Possibly.

> Should we/can we move over to making the markup subsystem hygienic by using
> define-syntax?
>
> (This is quite a big piece of work, and last time I tried looking at it, it
> seemed like it should be simple but made my head hurt).
> It's a translation exercise very like doing the document translation, and
> currently definitely needs to be done by a human being rather than software.

If we want backwards compatibility with Guile 1.8, we shouldn't move
to define-syntax, as it's not implemented in Guile 1.8.  :P

> Current plans once this is pushed is to tackle Tracker 1780 (Guile V2
> squawking with deprecation errors because of (format) calls without a
> destination parameter) and then get back to Tracker 1686 (tackling the issue
> of scheme compilation).

Sounds good, thanks Ian!