Re: Make accidental styles available as context mods. (issue 4819064)

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Montag, 5. September 2011, 21:25:50 schrieb Neil Puttock:
>> On 5 September 2011 20:10, David Kastrup <address@hidden> 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