Issue 4443: Don't pass current parser/location into #{...#} call

The construct #{...#} generates a call to a function embedded-lilypond.
After issue 4422, this call passed (*parser*)/(*location*) arguments
instead of the previous parser/location arguments needed for accessing
the respective values in a different lexical environment.  But since the
respective values are stored in GUILE fluids rather than in lexical
variables now, they are already passed implicitly and unnecessary as
function parameters.

diff --git a/scm/parser-ly-from-scheme.scm b/scm/parser-ly-from-scheme.scm
index 3a73e28c3558edf40c458dff821d82bcdc45c832..e0ee2961cd939dc4f8a0a797d4b66783d50c92f2 100644 (file)
--- a/scm/parser-ly-from-scheme.scm
+++ b/scm/parser-ly-from-scheme.scm
@@ -65,9 +65,8 @@ from @var{port} and return the corresponding Scheme music expression.
                                        (set! closures
                                              (cons `(cons ,p (lambda () ,expr))
                                                    closures)))))))))))
-    (define (embedded-lilypond lily-string filename line
-                               closures location)
-      (let* ((clone (ly:parser-clone closures location))
+    (define (embedded-lilypond lily-string filename line closures)
+      (let* ((clone (ly:parser-clone closures (*location*)))
              (result (ly:parse-string-expression clone lily-string
                                                  filename line)))
         (if (ly:parser-has-error? clone)
@@ -75,7 +74,6 @@ from @var{port} and return the corresponding Scheme music expression.
         result))
     (list embedded-lilypond
           lily-string filename line
-          (cons 'list (reverse! closures))
-          (list *location*))))
+          (cons 'list (reverse! closures)))))
 
 (read-hash-extend #\{ read-lily-expression)