Thomas Morley <thomasmorle...@gmail.com> writes: > 2016-07-01 7:05 GMT+02:00 David Kastrup <d...@gnu.org>: >> Thomas Morley <thomasmorle...@gmail.com> writes: > >>> %% works: >>> tstII = >>> \with { instrumentName = "foo" shortInstrumentName = "foo" } >>> \new Staff \tstII { r1 } >> >> Issue 4911 is supposed to harmonize this by stopping the second example >> from working. This makes it possible to recognize the syntax without >> knowing the type of \tstII in advance (could be a music expression, >> leading to completely different structure). > > I'm in two minds here. > Hormonizing code is always preferable, but being able to spare the > extra \with would be nice as well.
Why? There are technical considerations underlying this change that are also related to usability changes, like editors having a chance to properly identify and indent parts of an expression. It is not possible to let an argument-less scheme function work in the same manner/syntax as a fixed context modification works right now. Fixing that comes at a high cost, basically requiring special-casing scheme functions in a similar vein as now music/event functions are special-cased. Which is something that makes it impossible to create structures of music/event functions and other things. > To join both while letting it recognizable I tried: > > #(defmacro-public define-with-function rest > `(define-syntax-function ly:context-mod? ,@rest)) > > tstI = > #(define-with-function ()() #{ \with { instrumentName = "-name-" } #}) > > \new Staff \tstI { r1 } > > Doesn't work. > A mistake somewhere or is it all rubbish? Context mod functions are not special-cased. If you write (define my-music? (lambda (x) (ly:music? x))) (define-syntax-function my-music? ...) the result will stop working as a music function. Similar for event functions. But at the current point of time, those are the only two special-cased function types. I want to decrease rather than increase the number of special-cases here. >>> %%(3) >>> #(define (set-instrument-names-to-number-string nmbr mus) >>> (if (eq? (ly:music-property mus 'name) 'ContextSpeccedMusic) >>> (ly:music-set-property! mus 'property-operations >>> (list >>> (list >>> 'assign >>> 'instrumentName >>> (format #f "~a." nmbr)) >>> (list >>> 'assign >>> 'shortInstrumentName >>> (format #f "~a." nmbr)))) >>> mus) >>> mus) >>> >>> tst = >>> #(define-music-function (nmbr mus)(number? ly:music?) >>> (set-instrument-names-to-number-string nmbr mus)) >>> >>> \tst #3 \new Staff { r1 } >> >> Hm. At the current point of time, destructuring expression requires >> Scheme programming. And absorbing \new Staff into \tst #3 makes things >> much less flexible (\context Staff = "..." just becomes impossible >> then). > > Wasn't aware of this problem. Thanks spotting it. No, you misunderstand. This is not a problem with your code. It's rather a complaint that there is no reasonably better or more readable way to write your code while keeping it working for a similarly large number of use cases. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user