Great!
Everything very interesting.
In this case, drop is a lilypond music function, so I assume it will not
interfere with slri (but I don't know what slri is)
Cheers
D.
Il 18 gennaio 2019 01:21:31 CET, David Kastrup <d...@gnu.org> ha scritto:
>David Kastrup <d...@gnu.org> writes:
>
>> Valentin Villenave <valen...@villenave.net> writes:
>>
>>> 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.)
>>
>> You can use something like
>> (fold (if (negative? num) drop rise)
>> music
>> (make-list (abs num) 1))
>>
>> but I don't like creating lists for the sake of controlling loop
>size.
>
>By the way: `drop' is a function imported from (slri slri-1) and it's
>probably not a good idea to redefine it.
>
>--
>David Kastrup
--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
