Re: Context paths (and the Edition Engraver)

[Flaming Hakama by Elaine]

> ---------- 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"]


The square braces make it look like you're looking up an element in an
(associative) array, which is kind of what we're doing, if I understand
correctly.  That is, if StaffGroup (in a Context context) refers to all
StaffGroup contexts, and then we're narrowing this down by identifying one
by name, in this example, the one called "organ".

The parenthesis syntax makes it look more like a function call.   (So, it
might be clearer if it were called getStaffGroup)   However, the
parenthesis/function-call syntax makes it easier to identify multiple staff
groups by name, if it can take an array of names.  So, to identify all
voice contexts in all lower staves of three different staff groups:

StaffGroup("organ", "piano", "celeste").Staff("lower").Voice


I realize that the EE use case is more about identifying a very specific
context, in order to apply specific edits.

But, in general, from a context point of view, the general use case
involves identifying all or a subset of contexts.



Also, to comment on another previously suggested model for syntax,
the CSS selector approach is not a good one to model,
since its use of spaces and dots is not consistent with how they are used
here, to indicate sub-properties.

Which is to say, in CSS, dots between identifiers (with no spaces)
refer to multiple properties  of the same element,
and spaces are used to identify descendants.

For example:

<DIV id="foo" class="bar"><SPAN class="bar">confusion</SPAN></DIV>

.bar => matches both the outer DIV and inner SPAN
#foo .bar => matches the inner SPAN
#foo.bar => matches the outer DIV



Thanks,

Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
address@hidden
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-