Carl Sorensen <c_soren...@byu.edu> writes:
> What I meant to say was that I thought you would have some insight,
> and be able to identify whether there were any issues with the #{ #}
> syntax. The parser output shows that there are no issues with that
> syntax, so we need to find a better way to handle this shift in
> preparation for Guile 2.0.
#{ ... #} calls the parser when it is executed. The code, when quoted,
is
guile> '#{ \markup \override #'(box-padding . 0.4) \box
... ... \override #'(box-padding . 0.6) \box { $text }#}
(#<procedure embedded-lilypond (parser lily-string filename line closures)>
parser " \\markup \\override #'(box-padding . 0.4) \\box
... \\override #'(box-padding . 0.6) \\box { $text }" #f 0 (list
(cons 101 (lambda () text))))
That has an impact on performance. Since we are talking syntactical
replacements leading to typeset material here, the time for calling the
parser is usually negligible as compared to the time for actually
producing the corresponding output.
Obviously Ian's code does not like that. As his comment about the
snippet he can "easily fix" suggests, there are compatibility issues not
just with this code (which actually does nothing much out of the
ordinary regarding code used for generating code). Before he "fixes"
what he can and rips out what he can't, it would make sense to review
those issues and see whether one can do anything about them before
starting to work around them.
Because make no mistake: there will be user code around that will get
hit by that random breakage. Just "fixing" what is in Lilypond is not
enough.
My personal guess without looking at his code would be a timing problem
that leads to "text" not being known by the time it is compiled or
evaluated too often or too little. Getting macro code to evaluate at
the right time to keep the lexical nesting intact is tricky. For
example, it looks stupid that the generated (list ...) above created
from '#{ ... #} is not just a constant created by the reader, as this
would be faster. It would however, not work, since then the lambda
functions can't capture the meaning of "text".
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
