Re: Markup module patch (Issue 2026)

[Ian Hulin]

Hi David,
On 13/12/11 22:40, David Kastrup wrote:
> Ian Hulin <address@hidden> writes:
> 
>> Hi all, ..snip..
> 
> 
>> I'd like to deprecate this as I think it's nasty, smelly, evil
>> and kludgy
> 
> Care to explain why being able to use the same syntax as one uses
> in the main document is nasty, smelly, evil and kludgy?  Should we
> disallow \markup syntax in the main document as well?
> 
What is nasty is going back and forth between Lily and Scheme parsing
unnecessarily.
>> #(define-markup-command (double-box layout props text) (markup?) 
>> "Draw a double box around text." (interpret-markup layout props 
>> #{\markup \override #'(box-padding . 0.4) \box \override
>> #'(box-padding . 0.6) \box { $text }#}))
                                                        ^^^
The $text above LilyPond called from within Scheme called from within
LilyPond referencing a variable declared in the Scheme layer. I'm not
criticising the #{...#} stuff in itself, especially after you've been
working hard to clean this stuff up, but *here* it's adding another
layer of complexity to access the Scheme text variable.
Also the editorial thrust of the narrative in /extending/ seems to be
to use the Scheme macros.
>> and ask that users use
>> 
>> interpret-markup ( markup #:markup-command 'par ... ) instead.
>> 
>> We'd mark this as such in NEWS, meanwhile taking out the
>> offending examples from /extending/.
>> 
>> WDYT?
> 
> I think that there is nothing much out of the ordinary happening
> when the above command is being run, so it is quite likely that
> we'll get the same kind of breakage in other situations.
> 
> If I call
> 
> lilypond scheme-sandbox and enter (let ((text "xxx")) #{ \markup
> \override #'(box-padding . 0.4) \box \override #'(box-padding .
> 0.6) \box { $text }#})
> 
> I get (#<procedure line-markup (layout props args)> ((#<procedure 
> override-markup (layout props new-prop arg)> (box-padding . 0.4) 
> (#<procedure box-markup (layout props arg)> (#<procedure
> override-markup (layout props new-prop arg)> (box-padding . 0.6)
> (#<procedure box-markup (layout props arg)> "xxx"))))))
> 
> as result which is perfectly reasonable and does not expose the
> user to non-Lilypond syntax, let alone macro expansion.
> 
> Since you are the resident expert on Guile v2, it would be nice if
> you explained just what in Guile v2 happens to turn this into
> something nasty, smelly, evil and kludgy.
> 
You called me an expert, I didn't.  I'm just a stubborn sucker that
would like to see LilyPond working with a supported version of Guile.

In order to get the markup stuff to compile or be interpreted
correctly with Guile V2, I had to get the procedures validating the
markup commands to look in a single module at the list where they were
held. So I chose the base (lily) module. To keep it consistent, I got
the define-markup-command and define-markup-list-command macros to
push and pop the current Scheme module by doing
(let (prevmod (current-module))
     (existing declaration)
        ...
     (existing declaration))
  (set-current-module (resolve-module '(lily)))
  (existing code)
  ( ... )
  (set-current-module (prevmod))

> It is _exactly_ what the parser will deliver for this particular
> markup also in the main document, so if it breaks in #{ ... #}, it
> very likely also breaks in the main document.  Should we only be
> allowed to specify markups in Scheme macro syntax in future?
> 
The implication in the way /extending/ is written is that using the
macros is preferable in (define-markup-command) and
(define-markup-list-command).

What breaks is #{...#} within a #(define-markup-command ...) with the
patch.  I get this scheme traceback:

Validated markup command: line
Validated markup command: draw-lineBacktrace:
In /home/ian/src/lilypond/build/out/share/lilypond/current/scm/lily.scm:
 872: 10* [ly:parse-file "../programming-interface-test.ly"]
In /home/ian/src/lilypond/build/out/share/lilypond/current/ly/init.ly:
  48: 11* (let* ((book-handler #)) (cond (# #) (# #)))
  51: 12  (cond (# #) (# #))
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/lily-library.scm:
    ...
 213: 13  [ly:book-process #<Book> #< Output_def> ...]
In unknown file:
   ?: 14* [ly:optimal-breaking #<Paper_book>]
   ?: 15* [interpret-markup-list #< Output_def> ((# # # ...)) ...]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/markup-facility-defs.scm:
 569: 16* (let* ((stencils #)) (for-each (lambda # #) markup-list) ...)
 570: 17* [for-each #<procedure {#f} (m)> ((#<procedure
double-box-markup #> "A"))]
In unknown file:
   ?: 18* [#<procedure {#f} (m)> (#<procedure double-box-markup #> "A")]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/markup-facility-defs.scm:
 571: 19* (set! stencils (if (markup-command-list? m) (append! #
stencils) ...))
 572: 20* (if (markup-command-list? m) (append! (reverse! #) stencils)
...)
 575: 21  [cons ...
 575: 22* [interpret-markup #< Output_def> ((# # # ...)) ...]
 566: 23  [ly:text-interface::interpret-markup #< Output_def> ((# # #
...)) ...]
In unknown file:
   ?: 24* [double-box-markup #< Output_def> ((# # # # ...)) "A"]
   ?: 25* (let* () (interpret-markup layout props ...))
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/../programming-interface-test.ly:
   8: 26  [interpret-markup #< Output_def> ((# # # # ...)) ...
   9: 27* [embedded-lilypond {#f} ...]
In
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:
  67: 28  (let* (# #) (if # #) result)
  67: 29* [ly:parser-clone {#f} ((97 . #<procedure {#f} ()>))]

/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:67:21:
In procedure ly:parser-clone in expression (ly:parser-clone parser
closures):
/home/ian/src/lilypond/build/out/share/lilypond/current/scm/parser-ly-from-scheme.scm:67:21:
Wrong type argument in position 1 (expecting Lily_parser): #f

Why would temporarily changing the current module upset the LilyPond
parser?

I accept that it's best if I can fettle this patch so that we don't
need to deprecate anything.

Cheers,
Ian