Re: limitation in make-engraver?

[Thomas Morley]

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