Re: \consists terminology
Hi all, > "will include the following as one of many constituents > upon instantiation to be part of its translator group" \involves \incorporates ?? Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Hi David, On Fri, Jun 15, 2018 at 6:37 PM David Kastrup wrote: > > "consists of" and "will include the following as one of many > constituents upon instantiation to be part of its translator group" is > not the same. > > Well, if the latter of these is what "\consists" is intended to mean in this context, then I'm inclined to think that maybe my earlier pedantry might be on to something. Do you agree with the following: "A \consists B" is equivalent to "B constitutes [non-exclusively the relevant part of] A"? If that's the case, the active verb that goes in the opposite direction would be "comprise". Its negation could be "decomprise." You could also theoretically use "\invokes/\disinvokes" if that isn't already used elsewhere. David Foster Wallace, terrible person though he was, would likely have had a few better suggestions. Cheers, A ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
On 2018-06-15 09:03, David Kastrup wrote:
"consists of" and "will include the following as one of many
constituents upon instantiation to be part of its translator group" is
not the same.
I asked you to defend the hyperbolic "factually utterly wrong". At most
the distinctions are that of tense and a clarity of the underlying
mechanism. That is, "will include" is more of a promise of future
behavior than "consists of" which is present and absolute. Next, you
specified that the thing is part of a so-called translator group. Sure,
"consists of" is far too generic to cover that, so you would have to say
`\translatorGroupConsists` or equivalent to get to that level of
specificity. But documentation can easily supplement this by informing
people that contexts have translator groups, and that is where something
like an engraver lives.
Should we not avoid polluting a language with over-specification,
especially when it comes to implementation details that stand a chance
of being changed? So unless the distinction about translator groups is
truly important, `\consists` and "consists of" seem to be sufficient for
communicating the essentials.
Your point that `\remove` feels out of place is one I can agree with.
However, invented words like "unconsists" are not my cup of tea; though
to be honest, I wouldn't object too strongly provided we were unable to
track down something more suitable. And if there little reason to budge
on `\consists`, then our options may be limited.
Nope, I am totally serious here. How precisely would `\where`,
`\with`, and `\without` as stated here be in any way unclear or
incorrect? These are simpler words that are reasonably precise with
virtually no conflicting connotations.
\with is very extensively used.
\new Voice \where { \accidentalStyle piano } { ... }
is not just a massive change but also a change massively for the worse.
Your quoted example fails to justify why you think it would be for the
worse. The readings would be "create a new voice with an accidental
style of piano" versus "create a new voice where the accidental style is
piano". Both are equally very plain and direct. But I am willing to
concede there is a scenario in LilyPond where `\with` is definitely the
preferable term and/or that a supposed `\where` would be confusing
and/or wrong.
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
>> \enbike \debike > You mean \mount \unmount ? No… \addbiketoshed \removebikefromshed =) K. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Kieren MacMillan writes: >>> Another alternative might be \including and \excluding >> Or \engages / \disengages . So many bike sheds. > > \enbike \debike You mean \mount \unmount ? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Aaron Hill writes:
> On 2018-06-14 23:58, David Kastrup wrote:
>> Flaming Hakama by Elaine writes:
>>> Here is a usage of the \consists command:
>>>
>>> \context {
>>> \Staff
>>> \consists Mark_engraver
>>> \consists Metronome_mark_engraver
>>> }
>>>
>>> To convey what this does, it would be more along the lines of
>>> "Create a Staff context that consists of a Mark_engraver and
>>> Metronome_mark_engraver".
>>
>> Which forms a grammatical statement which, when interpreted at
>> its grammatical meaning, is factually utterly wrong.
>
> On 2018-06-15 06:54, David Kastrup wrote:
>> Engraver/translator instances are particular to a certain context. The
>> context exercises its contained translator_group implementation as the
>> main manner of its operation. If that sounds opaque it is because the
>> terminology at the C++ level is one incoherent mess.
>
> So, which way is it? Elaine's reading of `\consists` as "consists of"
> is entirely a plausible interpretation that seems to jive with how you
> describe how translators are instanciated as part of a context. What
> was (or is) "factually utterly wrong" about it?
"consists of" and "will include the following as one of many
constituents upon instantiation to be part of its translator group" is
not the same.
> With my fallacious ideas rent assunder, it seems like `\consists` is a
> perfectly fine word. `\consistsOf` or `\consistingOf` would certainly
> be more grammatically correct, but it sounds like you still have
> something against that.
They are breaking the reserved word conventions. Even while I want
those to stop being reserved words eventually, they are used in a place
where this kind of music function naming convention would be unusual.
>>> Finally, what about `\with` becoming `\where`? It reads just as
>>> plainly, and would free up the term if we wanted to opt for `\with`
>>> and `\without` as opposed to `\consists` and `\remove`.
>>
>> Frankly, by now I suspect that you did not actually close the sarcasm
>> tag you opened at the start of your comment.
>
> Nope, I am totally serious here. How precisely would `\where`,
> `\with`, and `\without` as stated here be in any way unclear or
> incorrect? These are simpler words that are reasonably precise with
> virtually no conflicting connotations.
\with is very extensively used.
\new Voice \where { \accidentalStyle piano } { ... }
is not just a massive change but also a change massively for the worse.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: \consists terminology
\bunk \debunk Mark -Original Message- From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of Kieren MacMillan Sent: Friday, June 15, 2018 8:38 AM To: David Kastrup Cc: Flaming Hakama by Elaine ; Lilypond-User Mailing List ; Carl Sorensen Subject: Re: \consists terminology >> Another alternative might be \including and \excluding > Or \engages / \disengages . So many bike sheds. \enbike \debike Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
>> Another alternative might be \including and \excluding > Or \engages / \disengages . So many bike sheds. \enbike \debike Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
On 2018-06-14 23:58, David Kastrup wrote:
Flaming Hakama by Elaine writes:
Here is a usage of the \consists command:
\context {
\Staff
\consists Mark_engraver
\consists Metronome_mark_engraver
}
To convey what this does, it would be more along the lines of
"Create a Staff context that consists of a Mark_engraver and
Metronome_mark_engraver".
Which forms a grammatical statement which, when interpreted at
its grammatical meaning, is factually utterly wrong.
On 2018-06-15 06:54, David Kastrup wrote:
Engraver/translator instances are particular to a certain context. The
context exercises its contained translator_group implementation as the
main manner of its operation. If that sounds opaque it is because the
terminology at the C++ level is one incoherent mess.
So, which way is it? Elaine's reading of `\consists` as "consists of"
is entirely a plausible interpretation that seems to jive with how you
describe how translators are instanciated as part of a context. What
was (or is) "factually utterly wrong" about it?
With my fallacious ideas rent assunder, it seems like `\consists` is a
perfectly fine word. `\consistsOf` or `\consistingOf` would certainly
be more grammatically correct, but it sounds like you still have
something against that.
Finally, what about `\with` becoming `\where`? It reads just as
plainly, and would free up the term if we wanted to opt for `\with`
and `\without` as opposed to `\consists` and `\remove`.
Frankly, by now I suspect that you did not actually close the sarcasm
tag you opened at the start of your comment.
Nope, I am totally serious here. How precisely would `\where`, `\with`,
and `\without` as stated here be in any way unclear or incorrect? These
are simpler words that are reasonably precise with virtually no
conflicting connotations.
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
How about \contains and \excludes? \contains says that we want a context to contain a particular kind of translator \excludes says that we want exclude a translator that would normally be included \includes and \excludes would be more a natural pair, but then there is a conflict between \include and \includes Another alternative might be \including and \excluding Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Carl Sorensen writes: > How about \contains and \excludes? > > \contains says that we want a context to contain a particular kind of > translator > \excludes says that we want exclude a translator that would normally be > included > > \includes and \excludes would be more a natural pair, but then there > is a conflict between \include and \includes > > Another alternative might be \including and \excluding Or \engages / \disengages . So many bike sheds. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Aaron Hill writes: > On 2018-06-15 03:29, David Kastrup wrote: >> Flaming Hakama by Elaine writes: >>> On Fri, Jun 15, 2018, 1:42 AM David Kastrup wrote: Sorry, this is not going at all in the direction you were aiming for but from a purely technical standpoint getting rid of \remove would be a much more worthwhile target than junking \consists , and \unconsists or something of similar awkwardness would be a lot less problematic as a newcomer than something as generic as \add . >>> >>> Quite the contrary. This is helping to elucidate what's actually going >>> on, and I suspect a more descriptive terminology may result. >> >> The less descriptive terminology has the advantage that it does not >> come >> as preloaded with precise but incorrect preconceptions. > > Why not call it `\xyzzy` then? Because it comes with no preconceptions, precise or fuzzy. > I would debate that preconceptions are the lesser evil when stacked up > against the potential of undescriptive and/or misleading terms. If > the terminology is not clear enough, then it is significantly harder > to correct or override a preconception. Of course, we should avoid > cluttering the user experience with all of the gory details of the > underlying mechanisms; but if folks are uncomfortable with the casual > reading of `\consists`, then it would seem that it is a poor word > choice indeed. I have seen a grammar complaint. > It truly is a shame that `\with` is already used, as the pair of > `\with` and `\without` could be a great way to succinctly state the > relationship in this scenario. Perhaps `\including` and `\excluding` > could work, but then... Too close to \include in my book which is something else entirely. > `\consists` seems to imply aggregation or possibly even containment. So? > This sounds like one of the incorrect preconceptions we are wanting to > avoid, since it is my understanding that the associated engravers, et > al. are *not* to be considered an element of the context that > `\consists` them. Not? > Rather, they co-exist and work along side during the process. Engraver/translator instances are particular to a certain context. The context exercises its contained translator_group implementation as the main manner of its operation. If that sounds opaque it is because the terminology at the C++ level is one incoherent mess. I don't see anybody stepping up to clean that up, however. At the LilyPond level, it is comparatively clean in comparison. I'd like to use something like \unconsists instead of \remove (why is this not in the third person singular like the rest anyway?) for comparatively relevant technical reasons. > So, `\including` might even be overstating the relationship here. > (Mind you, the confusion between `\including` and `\include` would be > more than enough to disqualify it anyway.) > > Could `\recognizes` and `\ignores` work? It's much much much more incorrect than what you are coming from. > These words, again, do not imply any form of ownership, rather are > hinting more at some form of permission, granting a translator to do > its work within that context. I would have suggested `\allows` and > `\denies` as simpler words, but the latter already exists along with > its pair `\accepts`. Oh, but now a crazy thought... Could overloading > those existing terms work? That is, would LilyPond be able to tell > the difference between `\accepts "SomeContext"` vs. `\accepts > "SomeEngraver"`? If so, then we could potentially throw away both > `\consists` and `\remove`. Accepting a subcontext into a hierarchy and instantiating a translator are so utterly different things that your request to conflate them in order to make things "more correct" is a complete absurdity. So what then would \defaultchild "some_translator" mean if those are comparable things? > Finally, what about `\with` becoming `\where`? It reads just as > plainly, and would free up the term if we wanted to opt for `\with` > and `\without` as opposed to `\consists` and `\remove`. Frankly, by now I suspect that you did not actually close the sarcasm tag you opened at the start of your comment. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
On 2018-06-15 03:29, David Kastrup wrote: Flaming Hakama by Elaine writes: On Fri, Jun 15, 2018, 1:42 AM David Kastrup wrote: Sorry, this is not going at all in the direction you were aiming for but from a purely technical standpoint getting rid of \remove would be a much more worthwhile target than junking \consists , and \unconsists or something of similar awkwardness would be a lot less problematic as a newcomer than something as generic as \add . Quite the contrary. This is helping to elucidate what's actually going on, and I suspect a more descriptive terminology may result. The less descriptive terminology has the advantage that it does not come as preloaded with precise but incorrect preconceptions. Why not call it `\xyzzy` then? I would debate that preconceptions are the lesser evil when stacked up against the potential of undescriptive and/or misleading terms. If the terminology is not clear enough, then it is significantly harder to correct or override a preconception. Of course, we should avoid cluttering the user experience with all of the gory details of the underlying mechanisms; but if folks are uncomfortable with the casual reading of `\consists`, then it would seem that it is a poor word choice indeed. It truly is a shame that `\with` is already used, as the pair of `\with` and `\without` could be a great way to succinctly state the relationship in this scenario. Perhaps `\including` and `\excluding` could work, but then... `\consists` seems to imply aggregation or possibly even containment. This sounds like one of the incorrect preconceptions we are wanting to avoid, since it is my understanding that the associated engravers, et al. are *not* to be considered an element of the context that `\consists` them. Rather, they co-exist and work along side during the process. So, `\including` might even be overstating the relationship here. (Mind you, the confusion between `\including` and `\include` would be more than enough to disqualify it anyway.) Could `\recognizes` and `\ignores` work? These words, again, do not imply any form of ownership, rather are hinting more at some form of permission, granting a translator to do its work within that context. I would have suggested `\allows` and `\denies` as simpler words, but the latter already exists along with its pair `\accepts`. Oh, but now a crazy thought... Could overloading those existing terms work? That is, would LilyPond be able to tell the difference between `\accepts "SomeContext"` vs. `\accepts "SomeEngraver"`? If so, then we could potentially throw away both `\consists` and `\remove`. Finally, what about `\with` becoming `\where`? It reads just as plainly, and would free up the term if we wanted to opt for `\with` and `\without` as opposed to `\consists` and `\remove`. -- Aaron Hill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology
Flaming Hakama by Elaine writes: > On Fri, Jun 15, 2018, 1:42 AM David Kastrup wrote: > >> David Kastrup writes: >> >> > Flaming Hakama by Elaine writes: >> > >> >> I think that conveys more clearly what is happening. >> > >> > Not really: that remains something to look up in the documentation. >> > >> > Now I'll readily admit that \consists / \remove does not make for an >> > appealing antonym pair. I'd be leary after all this time of turning a >> > common word like "add" into a reserved word even though "remove" is not >> > better in that regard. But at least it has the advantage of being >> > established. >> >> Some of my argument may be based on some tendency of arguing anything >> out of contrariness. However, this latter point has been irking me >> quite a bit as opposed to the quirky grammar you complain over. > > > It's not really a matter of quirky grammar. > > It's that the term does not convey the relationship in question. I doubt that we'll manage substantially better. >> While it would likely do nothing to address your complaint, actually >> moving to \consists / \unconsists would, while doubling down on the >> unnaturality you complain about, make for a better pairing, create a >> new keyword very unlikely to be in previous use and free \remove. >> > > So here's a question. > > Is \consist only used to express the relationship between contexts and > engravers? \consists, and basically yes (it's not just engravers but any translator of which engravers are just one subset). > Because if it's just used to with respect to engravers, you could > consider \addEngraver and \removeEngraver. We have translators named *_translator and translators named *_engraver and translators named *_performer . If you want to be precise, this kind of line does not actually add or remove an engraver anywhere but actually causes any context instantiated from the containing context definition to contain or not contain the respective engraver. It adds and removes the instruction to instantiate an engraver as part of instantiating a context from the current context definition. >> Sorry, this is not going at all in the direction you were aiming for >> but from a purely technical standpoint getting rid of \remove would >> be a much more worthwhile target than junking \consists , and >> \unconsists or something of similar awkwardness would be a lot less >> problematic as a newcomer than something as generic as \add . >> > > Quite the contrary. This is helping to elucidate what's actually going > on, and I suspect a more descriptive terminology may result. The less descriptive terminology has the advantage that it does not come as preloaded with precise but incorrect preconceptions. So the tradeoff is a really fuzzy one. > Based on Urs' comment, if it is more like registering a callback, how > about \register and \unregister? The "callback" is what is called a "listener". A translator is a whole collection of listeners as well as internal state and logic. That doesn't mean "register" is incorrect but we also register possible child context types. So it's again more a case of a really fuzzy tradeoff. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \consists terminology (was: Advice on naming and structuring scholarLY commands)
On Fri, Jun 15, 2018, 1:42 AM David Kastrup wrote: > David Kastrup writes: > > > Flaming Hakama by Elaine writes: > > > >> I think that conveys more clearly what is happening. > > > > Not really: that remains something to look up in the documentation. > > > > Now I'll readily admit that \consists / \remove does not make for an > > appealing antonym pair. I'd be leary after all this time of turning a > > common word like "add" into a reserved word even though "remove" is not > > better in that regard. But at least it has the advantage of being > > established. > > Some of my argument may be based on some tendency of arguing anything > out of contrariness. However, this latter point has been irking me > quite a bit as opposed to the quirky grammar you complain over. It's not really a matter of quirky grammar. It's that the term does not convey the relationship in question. While > it would likely do nothing to address your complaint, actually moving to > \consists / \unconsists would, while doubling down on the unnaturality > you complain about, make for a better pairing, create a new keyword very > unlikely to be in previous use and free \remove. > So here's a question. Is \consist only used to express the relationship between contexts and engravers? If not, what are the other entities that are related by way of \consist? Because if it's just used to with respect to engravers, you could consider \addEngraver and \removeEngraver. > Sorry, this is not going at all in the direction you were aiming for but > from a purely technical standpoint getting rid of \remove would be a > much more worthwhile target than junking \consists , and \unconsists or > something of similar awkwardness would be a lot less problematic as a > newcomer than something as generic as \add . > Quite the contrary. This is helping to elucidate what's actually going on, and I suspect a more descriptive terminology may result. Based on Urs' comment, if it is more like registering a callback, how about \register and \unregister? Thanks, ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
