Re: ly:parser-parse-string again

[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.

> 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?

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

-- 
David Kastrup