Reinhold Kainhofer <reinh...@kainhofer.com> writes:
> Am Montag, 5. September 2011, 21:25:50 schrieb Neil Puttock:
>> On 5 September 2011 20:10, David Kastrup <d...@gnu.org> wrote:
>> > I suggest trying the following Lilypond fragment out.
>> >
>> > #(define (make-accidental-mod style)
>> > "Make a context modification from accidental style @var{style}."
>> > (let ((style-settings '(1 2 3 4)))
>> > #{ \with { extraNatural = #(cadr $style-settings)
>> > autoAccidentals = #(caddr $style-settings)
>> > autoCautionaries = #(cadddr $style-settings) } #}))
>> > #(display (make-accidental-mod 'modern))
>>
>> Heh, silly me. I was rather stupidly testing it with \set, which
>> naturally causes the parser to complain.
>>
>> I suppose this means ly:make-context-mod is redundant then.
>
> I would still keep it so that one can create a context-mod directly in
> scheme without resolving to a #{..#} block...
#{..#} _is_ a direct Scheme construct interpreted at _read_ time in the
Scheme reader. It is enabled in scm/parser-ly-from-scheme.scm with the
line
(read-hash-extend #\{ read-lily-expression).
Within Lilypond, there is no place where you can read Scheme source but
not a #{...#} construct except in the load order before
scm/parser-ly-from-scheme.scm. But when in doubt, the load order can be
fixed. Things like scm/parser-ly-from-scheme.scm obviously belong early
in the load order, along with macro definitions.
So "directly in Scheme" is a mischaracterization, and there is about as
little utility to "without resolving to a #{..#} block" as there is to
"without resolving to a macro call".
Guile 2.0 caused surprises with macro calls, and it might cause
surprises with read-hash-extend. Either will warrant fixing rather than
avoiding.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
