Context paths (and the Edition Engraver)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Flaming Hakama by Elaine
> ---------- Forwarded message ----------
> From: David Kastrup <[hidden email]>
> To: Dan Eble <[hidden email]>
> Cc: [hidden email]
> Bcc:
> Date: Tue, 21 Jan 2020 22:51:29 +0100
> Subject: Re: Context paths (and the Edition Engraver)
> Dan Eble <[hidden email]> writes:
>
> > On Jan 21, 2020, at 14:37, David Kastrup <[hidden email]> 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*"
[hidden email]
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

David Kastrup
Flaming Hakama by Elaine <[hidden email]> writes:

>> ---------- Forwarded message ----------
>> From: David Kastrup <[hidden email]>
>> To: Dan Eble <[hidden email]>
>> Cc: [hidden email]
>> Bcc:
>> Date: Tue, 21 Jan 2020 22:51:29 +0100
>> Subject: Re: Context paths (and the Edition Engraver)
>> Dan Eble <[hidden email]> writes:
>>
>> > On Jan 21, 2020, at 14:37, David Kastrup <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Jan-Peter Voigt
In reply to this post by Dan Eble
Am 21.01.20 um 18:50 schrieb Dan Eble:

> On Jan 21, 2020, at 11:31, Jan-Peter Voigt <[hidden email]> wrote:
>> I'd like that, though it would be a quite invasive change.
>> And if we stay with the string for the context id and then use
>> lists/paths in the \context statement like
>> \new Staff = "choir" << \new Voice = "soprano" …
>>
>> and then use
>> \context Voice = choir.soprano
>>
>> it would be inconsistent with \new <Context> = "…"
>>
>> I will write down some more text about this topic later.
>
> I see similarities with languages like CSS and XPATH select nodes in a DOM.  Notation borrowed directly from them will not integrate well into LilyPond, but it might be fruitful to ask how we could modify expressions like these to fit in.
>
>     %% find the voice in the example quoted above, very specifically
>     \context Staff#choir > Voice#soprano { … }         % CSS
>     \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH
>
>     %% ditto, but using context type only
>     \context Staff > Voice { … }                       % CSS
>     \context Staff/Voice { … }                         % XPATH
>
>     %% ditto, but using ID only
>     \context #choir > #soprano { … }                   % CSS
>     \context [@id=choir]/[@id=soprano] { … }           % XPATH
>
>     %% find the context where the rehearsalMark property is defined
>     \context [rehearsalMark] { … }                     % CSS
>     \context [@rehearsalMark] { … }                    % XPATH
> —
> Dan
>

I am amazed what kind of discussion is raised on this topic :)

I'd suggest alternative commands to create something like an
XQuery/CSS/whatever functionality. Elsewhere in this thread David (K)
answered to syntax ideas that would break the current model.

To have the possibility to address contexts *like* in CSS has some
appeal. But IMHO it shouldn't disturb the current input scheme. So
alternate commands might help here.
Perhaps *like*:

\getContext the.path.to.the.context

... or ...

\getContext \thisContext."..".otherContextsName

*don't know if implementing \thisContext is trivial*

The idea that an ID of a context is a list and not a string does attract
me, but I see a major change that has to be done very carefully.

If the ID is a string (or symbol) the path can be easily constructed
with ly:context-parent.
Something like:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\version "2.19.83"

logContextPath = \applyContext
#(lambda (context)
   (define (context-path context)
     (let ((parent (ly:context-parent context)))
       (if (ly:context? parent)
           `(,@(context-path parent) ,(ly:context-id context))
           (list (ly:context-id context)))
       ))
   (ly:message "context path: ~A" (context-path context)))

\new Score = "mymusic" {
  \new StaffGroup = "choir" <<
    \new Staff = "soprano" <<
      { c''4 \logContextPath } \\
      { g'4 \logContextPath }
    >>
  >>
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


Just some thoughts.

I hope to be able to write some more text about it soon.
But I have another task that will take up a lot of my time in the coming
weeks. You are welcome to ask me questions which I will try to answer.
But I will not be able to be active for the next weeks.

Jan-Peter

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan
Hi Jan-Peter (et al.),

> I am amazed what kind of discussion is raised on this topic :)

Me, too. Maybe we should have international music engraving conferences more often than once every 20 years…  ;)

> I'd suggest alternative commands to create something
> like an XQuery/CSS/whatever functionality.

+1

> To have the possibility to address contexts *like* in CSS has some
> appeal. But IMHO it shouldn't disturb the current input scheme.

+1

> If the ID is a string (or symbol) the path can be easily constructed
> with ly:context-parent. Something like:

Nice!
(Aside: Now that I’ve gotten past my Schemenangst, I look at that code and immediately see how it works and its potential uses and extensions.)

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


12