Re: Context paths (and the Edition Engraver)

[David Kastrup]

Flaming Hakama by Elaine <address@hidden> writes:

>> ---------- Forwarded message ----------
>> From: David Kastrup <address@hidden>
>> To: Dan Eble <address@hidden>
>> Cc: address@hidden
>> Bcc:
>> Date: Tue, 21 Jan 2020 22:51:29 +0100
>> Subject: Re: Context paths (and the Edition Engraver)
>> Dan Eble <address@hidden> writes:
>>
>> > On Jan 21, 2020, at 14:37, David Kastrup <address@hidden> wrote:
>> >>
>> >> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
>> >
>> > OK.  It would be an understandable growth on the current face of
>> LilyPond. :)
>> >
>> > Questions follow, but I'm not asking you to spend time investigating.
>> >
>> > Do you think we could achieve making the quotes optional for some
>> > simple IDs, and making the whitespace optional?
>> >
>> >     StaffGroup=organ.Staff=upper.Voice.SubVoice=2
>>
>> It would all be optional (except in \lyricsmode or \markup) but I am
>> skeptical that it would make for a great convention.
>>
>> > In a situation where the user didn't care to constrain the context
>> > types, do you think could they be omitted, or would we have to invent
>> > a placeholder?
>> >
>> >     =organ.=upper..=2
>> >     X=organ.X=upper.X.X=2
>>
>> I don't think that this would be a reasonable syntax.
>
> Just chiming in to agree that this syntax is not very clear.
> At least, I find it confusing to see what looks like multiple assignments
> (use of =) on the same line.
> The = in this case is not being used in this case to define something, but
> to identify something that presumably already exists.
>
>
> Is there any hope of having syntax like one of the following?
>
> StaffGroup("organ").Staff("upper").Voice.SubVoice("2")
> StaffGroup["organ"].Staff["upper"].Voice.SubVoice["2"]

Not as much "hope" as "horror".  This does not fit at all into current
LilyPond syntax.

I mean, something like

"[" = <>[
"(" = <>(

{ \new Voice[c'8 d' e'] (g' c''2) }

is valid code.  Not a good idea at all, but stopping the parser from
working with it in order to give it a different meaning would cause a
whole lot of wreckage.

And what LilyPond can reasonably parse in the context of music functions
falls into comparatively narrow classes and requires a lot of planning
and magic behind the scenes.

-- 
David Kastrup