Re: Generate pdf from scheme function

[Alexandre Araujo Moreira]

Thanks for everything, guys. I just tested what David said on 2.17 and it worked for the case I described here. Problem is, when I try to add a \header block inside it I start getting errors again. Considering how many problems I've faced so far regarding this, I feel I'm trying to push the scheme-functions in a direction they're not intended to go, is that correct?

So far I managed to achieve the overall results I want \include-ing a couple files (one above the information I want to supply setting default values for some global variables, the melody and other variables set in the main file, then another included file below it all containing the structure I wanted my "macro" to generate. It's not the best result but it's a good trade-off so far.

Am I missing another, better, way to do it programmatically? Or are scheme-functions actually intended to do what I'm failing to do and I'm just using them wrong?

On Mon, Mar 18, 2013 at 5:07 AM, David Kastrup <address@hidden> wrote:

Alexandre Araujo Moreira <address@hidden> writes:

>>          Alexandre Araujo Moreira <address@hidden> writes:
>>
>>     > \version "2.16.2"
>>     > simpleMusic =
>>     > #(define-scheme-function (parser location melody) (ly:music?)
>>     > #{
>>     > \score {
>>     > $melody
>>     > \layout {}
>>     > }
>>     > #})
>>     > \simpleMusic { c1 }
>>     >
>>     > Is there anyway I can write something similar to simpleMusic (in
>>     > usage), where it'll automatically generate the pdf given the notes?
>>
>>     \version "2.16.2"
>>     simpleMusic =
>>     #(define-scheme-function (parser location melody) (ly:music?)
>>     #{
>>     \score {
>>     $melody
>>     \layout {}
>>     }
>>     #})
>>
>>     \score { \simpleMusic { c1 } }
>>
>>     Probably more verbose than you care for, but at least you can get
>>     midi and layout blocks in which is more than you can do using a
>>     music function.
>>
>>
>> David, I tried what you said above (and some variations, as having a
>> score around another score seemed odd)

It is not a "score around another score" in LilyPond-think, but rather a
score syntactically introduced with \score and then being constructed
inside by referring to a score variable.  Things work similarly with
\book and \bookpart variables.

>> and I only managed to get syntax errors.

This is probably my fault: I don't have 2.16 installed but did not
change the version header to reflect this in my posting.  The above code
works fine in current 2.17.  I did not remember that the changes were
not already in 2.16.

>> My original idea was based on believing a "scheme-function" in
>> Lilypond was more-or-less like a macro in Scheme. Now I think I was
>> wrong about that.

No, you are quite correct, particularly regarding the "more-or-less"
part.  Working on the "more" part is ongoing work, however.

>> Is there any facility in Lilypond that would allow me to write
>> something like
>>
>> \myMacro arg1 arg2 and have lilypond behave as if I had wrote the
>> expansion of myMacro over arguments arg1 and arg2? If there is such a
>> thing I can work out a way in which it could behave the way I want.
>> Especially if I have anything like guile's syntax-case at my
>> disposal.

The problem is not as much defining such functions but rather to get
them accepted everywhere where you would expect.  This is a gradual
process.  I had some attempts to turn this into an all-or-nothing
feature where you could use Scheme functions wherever a variable was
possible.  It turns out that this is quite tricky: variables in the
syntax generally know their type, and Scheme functions know their type
only after being called which requires their argument list to be parsed
(and evaluated) first.

The parser generally uses one token of "lookahead" to make its
decisions, and whenever the syntax depends on the type of a variable,
the "lookahead" required for finding the end of a Scheme function's
argument list call interferes with the not-yet made decision about the
_expression_'s type.

It is the goal to eventually get rid of all these fine distinctions and
limitations, and 2.17 is a solid step forward from 2.16 in that regard.

--
David Kastrup


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

--
"Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies."
- As seen in 'How to Design Programs'