On Sun, Dec 4, 2011 at 1:20 PM, David Kastrup <[email protected]> wrote:
> I don't see why you would be using make-parameter at all, and why you
> would be creating a parameter of type _letter_ when you actually _need_
> a symbol. Then write a macro around it that needs to do some partial
> evaluation using primitive-eval in order to evaluate one half of a
> construct in advance but not the other and you already have one added
> layer of diddling with evaluation order using macros...
Yes, I should get more acquainted with macro syntax, pseudo-quote, unquote etc.
> I protest in the name of geeks against this characterization.
Well, there **is** a documented trend of *not* doing things the
simpler way just "because we can" do it otherwise... Granted, that
doesn't say anything about elegance. Or maintainability :-)
> I don't get it. It's like you want to put a nail into a wall, and miss
> with a hammer, so you take a shoe and complain to the producer of the
> hammer that the nails are really hard to drive using a shoe.
Sure.
> You can use `$' with a Scheme expression anywhere you could use
> `\NAME' after having assigned the Scheme expression to a variable NAME.
> This replacement happens in the `Lexer', so Lilypond is not even aware
> of the difference.
That's promising. I've often wished I could do that.
> One drawback, however, is that of timing. If we had been using `$'
> instead of `#' for defining `newLa' in the above example, the Lexer
> would have evaluated the Scheme code right away in order to figure out
> the kind of the next token before Lilypond would have had a chance for
> executing the assignment. Consequently, the Scheme definition would
> have failed because `traLaLa' would not yet have been defined. As a
> rule, using `#' rather than `$' whenever it is allowed will cause fewer
> surprises.
That's what I'm gradually realising. Which makes the change less
"disruptive" that it seemed at first.
> Uhm, "avoid this kind of lock-in hack programming", not support it
> better. The regtests are for features that should not stop working
> without good reason. This includes ly:parser-include-string and
> eval-string. But that does not imply that what you use them for is a
> good idea.
Never said that, never will.
> describeMusic =
> #(define-music-function (parser location description music) (string?
> ly:music?)
> (set! (ly:music-property music 'description) description)
> music)
>
> hideNotes =
> \describeMusic "This hides notes"
> {
> ...
> }
Interesting. I think this discussion took place when we started
documenting music-functions-init.ly, and were wondering how to
document property-init.ly in a similar way.
However, my point here was mostly about what I described in the linked
git commit:
(define (foo) bar) isn't evaluated quite exactly like (define foo
bar), only the former of which allows for docstrings. So I'm not sure
how to properly document (define foo bar), other than in comments.
Anyway. Attached is a patch that I'd suggest for the two oddities
you've been addressing earlier. (I'm not sure this deserves a rietveld
entry, and I'm a bit rusty wrt git-cl.)
Thoughts?
Cheers,
Valentin.
From 556368a6e899d753aea358df2e7847a0727b21c9 Mon Sep 17 00:00:00 2001
From: Valentin Villenave <[email protected]>
Date: Sun, 4 Dec 2011 15:38:52 +0100
Subject: [PATCH] Add regtests for Scheme strings inclusion/evaluation.
This commit expands include-string.ly and adds another
test for eval-string. Include-string.ly has been
renamed scheme-include-string, for consistency's sake.
---
input/regression/include-string.ly | 8 --------
input/regression/scheme-eval-string.ly | 22 ++++++++++++++++++++++
input/regression/scheme-include-string.ly | 14 ++++++++++++++
3 files changed, 36 insertions(+), 8 deletions(-)
delete mode 100644 input/regression/include-string.ly
create mode 100644 input/regression/scheme-eval-string.ly
create mode 100644 input/regression/scheme-include-string.ly
diff --git a/input/regression/include-string.ly b/input/regression/include-string.ly
deleted file mode 100644
index 5c88e94..0000000
--- a/input/regression/include-string.ly
+++ /dev/null
@@ -1,8 +0,0 @@
-\version "2.14.0"
-
-\header {
- texidoc = "@code{ly:parser-include-string} should include the current
-string like a file @code{\\include}."
-}
-
-#(ly:parser-include-string parser "\\relative c' { a4 b c d }")
diff --git a/input/regression/scheme-eval-string.ly b/input/regression/scheme-eval-string.ly
new file mode 100644
index 0000000..73cf621
--- /dev/null
+++ b/input/regression/scheme-eval-string.ly
@@ -0,0 +1,22 @@
+\version "2.15.21"
+
+\header {
+ texidoc = "Arbitrary strings may be evaluated in a Scheme expression.
+However, in most cases it is recommended to use
+@code{ly:parser-include-string} instead.
+"
+}
+
+var = \relative c' { c1_"you shouldn't be seeing this" }
+
+defineVar =
+#(define-music-function (parser location name) (string?)
+ (eval-string (format #f
+ "(define-public ~a
+ #{ \\relative c' { a4 b c d } #} )"
+ name))
+ (make-music 'Music 'void #t ))
+
+\defineVar "var"
+
+\new Staff \var
diff --git a/input/regression/scheme-include-string.ly b/input/regression/scheme-include-string.ly
new file mode 100644
index 0000000..9e21471
--- /dev/null
+++ b/input/regression/scheme-include-string.ly
@@ -0,0 +1,14 @@
+\version "2.15.21"
+
+\header {
+ texidoc = "@code{ly:parser-include-string} should include the current
+string like a file @code{\\include}, thus allowing for toplevel
+expressions.
+"
+}
+
+var = \relative c' { c1_"you shouldn't be seeing this" }
+
+#(ly:parser-include-string parser "var = \\relative c' { a4 b c d }")
+
+\new Staff \var
--
1.7.7.4
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
