Re: Patch: Make #{ ... #} wagonloads more useful

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 8/27/11 4:41 PM, "David Kastrup" <address@hidden> wrote:
>
>> David Kastrup <address@hidden> writes:
>> 
>>> Previously #{ ... #} created only sequential music.  This changes it to
>>> accept everything an assignment accepts.  Incompatibility to before:
>>> #{ #} returns a void music expression, #{ music #} does not create a
>>> sequential music list but just a single music event,
>
> I assume that if you want to get a sequential music, you could do
>
> #{ {music} #}

Sure.

>> Ugh.  But with the new patch, this can be reduced to
>> 
>>     F = ##{-\tweak #'font-size #-3 -\flageolet#}
>> 
>> If you check the resulting expressions, you'll find that apart from the
>> added origin property they are identical.
>> 
>> Is that smooth or what?
>
> What, are you trying to make it easy for users to do complicated things?
> Why in the world would you want to do that?
>
> This is WAY cool.  Thanks!

Well, the regtests finally threw out another regression: assignments
don't work inside of ly:parser-parse-string since it no longer expects a
Lilypond document but an assignable expression, and those can't be
assignments themselves.

It is not really relevant for #{ ... #} since that basically did
ly:parser-parse-string on
"parseStringResult = \notemode { ... }" and thus did not accept
assignments either.

The question is whether this incompatibility in ly:parser-parse-string
is desirable, or whether it warrants introducing a separate function,
say ly:parser-parse-expression, for doing this kind of work.

Probably the latter.

-- 
David Kastrup