On 1/18/19, David Kastrup <d...@gnu.org> wrote:
> This is not really an issue for string-manipulation.

Agreed. Nevertheless, I was pleasantly surprised to see that
ly:parser-include-string could accept an incomplete expression.
(Previously, ly:parser-parse-string would have been much less flexible
here.)

> Let's rather do this in a sane manner:

Indeed, a named "let" loop is clearly the preferred way to go!

That being said, I still wonder if there’d be any way of making it
work with either iota or make-list without having to go through string
manipulations. (It would remove the need for a loop with an
incremented counter.)

And btw, why does mapping onto (iota num) require a lambda (x)
function even though that x argument does absolutely nothing? My
instinct would be to use lambda (), but that throws an error.

>            ((negative? num) (loop (1+ num) #{ \drop 1 #music #}))
>            (else (loop (1- num) #{ \rise 1 #music #})))))

Why #music and not $music inside the #{ #}? (I suspect there’s no
difference in this case, but $music is the more familiar syntax
inherited from before your parser/lexer improvements.)

V.

_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to