https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm File scm/lily.scm (right):
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode111 scm/lily.scm:111: "This defines a variable @var{name} with the starting value On 2020/02/01 21:37:50, dak wrote: > An interesting DOC string method... define-syntax doesn't have anything like > that? no, doesn't look like it. I added all the GUILE repos I could find to cs.bazel.build, none of the define-syntax uses seem to have doc strings. See https://cs.bazel.build/search?q=define-syntax%20f%3ascm%20&num=450 https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode123 scm/lily.scm:123: (define-syntax define-session On 2020/02/01 21:37:50, dak wrote: > The problem with define-syntax is that in Guile-1.8, it doesn't work properly > because of some symbol changing behavior when defined, a bug that will not get > fixed any more. I wish I'd remember what it was. It was something short like > \once or \temporary or so. One could use it in the LilyPond core, but it failed > in user documents. Ah right: pretty sure it was \void (namely the symbol 'void > being bound to something). > > That makes it hard for people to get acquainted with it and maintain it in > consequence. So let's see whether we manage to muddle through in a different > manner. Do you have a useful test case? Should I just draw out the > define-session thing and try to convince Guile-2.0 with the right incantations > to byte compile it? I assume this is the same in Guile-2.2 (for which I have an > Ubuntu package I don't need to compile)? > > Would this give us a chance to get somewhere? Please see Taylan's reply to the guile-devel list, which gives a succinct explanation of why inner functions in macros can never work in the Guile 2.x compiler. So we either forego compilation (at a 1.5 sec startup cost) or we rewrite the macros to stop using inner functions. What is the problem precisely with void ? I assume that is not about define-session but for define-music-function, which looks like it has a very complex macro expansion. Can you provide a repro scenario? Another option: we decide that as of LilyPond 2.21, you will need GUILE 2.2 for LilyPond, and then we can rewrite the Scheme code without having to worry about G1.8 bugs. With the performance tuning on BDWGC, I think this a viable strategy too. https://codereview.appspot.com/553480044/
