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 <d...@gnu.org> wrote:
> Alexandre Araujo Moreira <alexandr...@gmail.com> writes:
>
> >> Alexandre Araujo Moreira <alexandr...@gmail.com> 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
> lilypond-user@gnu.org
> 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'
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
