[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: limitation in make-engraver?
From: |
Thomas Morley |
Subject: |
Re: limitation in make-engraver? |
Date: |
Sat, 4 Mar 2017 00:30:02 +0100 |
2017-03-03 0:13 GMT+01:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> Hi,
>>
>> it looks like the make-engraver-makro fails to accept certain variables.
>>
>> In the code belowe 3 engravers are defined using different syntax. All
>> three try to use a predefined variable.
>> The first, defined with make-engravers fails.
>>
>>
>> \version "2.19.52"
>>
>> #(define ev 'note-event)
>>
>> #(define test-engr
>> (lambda (context)
>> (make-engraver
>> (listeners
>> (
>> (ev engraver event)
>> ;(note-event engraver event)
>
> ev is the same as 'note-event, not note-event.
>
> make-engraver is a macro. It (obviously) does not evaluate a lot of the
> structure but converts it into something else. Creating such a macro in
> your own manner will most of the time require using, well, a macro
> (which gets unexpanded arguments and expands its result). Or you use a
> function but call primitive-eval on its result.
>
>> (write ev)
>> (format #t "\n\nnote-event found from test-engraver\n"))))))
>>
>> #(define test-I-engr
>> (lambda (context)
>> `((listeners
>> (
>> ,ev
>> ;note-event
>> .
>> ,(lambda (engraver event)
>> (write ev)
>> (format #t "\n\nnote-event found from test-I-engraver\n")))))))
>>
>> #(define test-II-engr
>> (lambda (context)
>> (list
>> (cons 'listeners
>> (list
>> (cons
>> ev
>> ;'note-event
>> (lambda (engraver event)
>> (write ev)
>> (format #t "\n\nnote-event found from
>> test-II-engraver\n"))))))))
>> \layout {
>> \context {
>> \Voice
>> \consists #test-engr
>> %\consists #test-I-engr
>> %\consists #test-II-engr
>> }
>> }
>>
>> {
>> c'4
>> }
>>
>> Am I missing something or is it a limitation of make-engraver?
>
> Like define , some of its "argument" contains symbols that are never
> evaluated but used directly. You cannot deliver them with an expression
> unless you add a separate explicit expansion step instead of relying on
> normal Scheme parsing for evaluating the macro.
>
> --
> David Kastrup
Thanks for your explanations.
I'm not sure I understand all and in depth, but lemme think about it,
probably doing some experiments.
Maybe I come back for details.
Thanks,
Harm