Re: ly:parser-parse-string again

[Urs Liska]

Am 05.07.2016 um 18:01 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Am 05.07.2016 um 16:00 schrieb David Kastrup:
>>> Urs Liska <address@hidden> writes:
>>>
>>>> Well, first of all I wouldn't have thought of it, so I felt very
>>>> embarrassed at first. But actually the problem is that my function is
>>>> kind of an adaptor. It includes a number of files (i.e. all from a
>>>> directory that match a pattern), and each file defines the same
>>>> variables (e.g. \music, \lyricText and \bcFigures). The function wants
>>>> then to either rename them so they can independently be used in a score
>>>> or rather store them in a tree where the function building the score
>>>> will later fetch them from.
>>>>
>>>> So, within my function I have to iterate over the list of files, include
>>>> them and process the variables that are defined within the files.
>>> So build a string that includes the list of files and processes the
>>> variables.
>>>
>> Argh.
>> Yes, it's tedious to build that string, even within a loop.
> Use
>
> (with-output-to-string
>   (lambda ()
>     ...
>
> for building the string.  That makes the control flow of your program
> independent from the structure of the string you piece together.

Thanks for that pointer. Indeed it makes the code much cleaner.

For anybody interested, the results are visible at
https://git.openlilylib.org/bfsc/kayser/blob/karlsruhe/includes/lib/file-handling.ily#L124

>
>> But it works, and the include works as well.  Thanks for the pointers
>> - I wouldn't have thought in that direction because it would have felt
>> like just another level of indirction although it is actually the
>> opposite.
> The alternative is cloning a fresh parser.  There might be some
> incentive to carry over the current notename language automatically.
> But it does not make sense to carry over the whole state stack when
> cloning.  So what to do if we are not actually in notemode currently?

Makes sense.
But actually one would rather expect the default to be active just like
with regular files.
I don't specify a language in the regular .ly file, so it would be
natural to have Dutch as the default in include files as well.
But the other approach is significantly cleaner anyway, so I'm happy now.

Urs

>
> That's all in a bit of an icky state.
>