\markup* and Guile V2 - was Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050)

[Ian Hulin]

Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite
gang,

Here is a bulletin from the Guile V2 migration cave.

I am currently brewing a patch for Tracer 1686.

The markup facility as written is a major PITA when running with Guile
V2, and is currently blocking progress on this patch.

1. The markup facility code needs to be in a Scheme module
   (scm markup-facility-defs), or (scm markup-macros) or some such
   for clean backwards compatibility between Guile V1.8 and Guile 2.

   This is so that lily.scm can load all the things in the current
   load list using either Guile 1.8 or Guile V2 and can also
   byte-compile each loaded file using Guile V2 so that the compiled
   file can be loaded next time LilyPond fires up to gain performance.

2. Using a module for markup exposes brittleness in the markup code
   when using Guile V2. Basically I have moved all the declarations in
   markup-macros and markup to markup-macros.scm, which defines the
   new (scm markup-macros) module.  There is a
   (use-modules (scm markup-macros) call in lily.scm.
   Guile V2 is fussier about things like forward-referencing macros and
   syntax forms before you declare them (i.e. using lazy bindings for
   macros).

   2.1 We can fix things with macros declared at Scheme level by moving
       declarations to other .scm files and juggling the load order in
       lily.scm.

   2.2 However, things get nastier when we get into the
       define-markup-commands.scm file and using the markup, markup*,
       define-markup-command and define-markup-command-list macros.
       Here we are doing on-the-fly parsing and interpreting and
       things tend to fall over under Guile V2's stricter régime.

       2.2.1 Firstly, the commands in the file have to be re-ordered so
             that the #<markup> forms are not referenced before
             they are used.  E.g. #line form is used internally in
             procedure calls contained within a define-markup-commmand
             macro for (define-markup-command draw-line ...)
             before (define-markup-command line) is declared.  There
             are several more examples within the file.

       2.2.2 If things are not in the right order you may get lucky and
             get a fairly unhelpful message
             "Not a markup command: <markup>".  This is the call
             to lookup-markup-command failing to return a pair within
             compile-markup-command, which is called from
             compile-all-markup-commands, which is called from
             the markup or markup*, which may or may not have been
             called recursively from higher-level
             define-markup-command<mumble> call.

       2.2.3 Some of the definitions just give you a gnostic
       "source expression failed to match any pattern in form <blah>"
             which may imply we're running into macro hygiene issues.

    2.3 We may need think about using using (define-syntax for the
        macro definitions in the markup facility if hygiene is indeed
        an issue.

This is just to let you know if you're planning on major surgery on
the syntax front, the markup module issue needs to be addressed as well.

Hope this informs your discussions about changes to markup and if any
of you have any insights into what I've found while while working I'd
appreciate your input, as I'm getting a bit stuck. I want to be able
to concentrate on sorting out the changes to lily.scm and main.cc and
validating running up lily under Guile V2. For me the markup facility
is a bit of a side issue.

Cheers,

Ian Hulin


On 23/10/11 22:08, address@hidden wrote:
> LGTM.  You'll be happy to know that Mike and I are currently trying
> to get rid of \markuplines, so that there will only be a \markup
> command.
> 
> http://codereview.appspot.com/5312050/