lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \consists terminology


From: David Kastrup
Subject: Re: \consists terminology
Date: Fri, 15 Jun 2018 15:54:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> On 2018-06-15 03:29, David Kastrup wrote:
>> Flaming Hakama by Elaine <address@hidden> writes:
>>> On Fri, Jun 15, 2018, 1:42 AM David Kastrup <address@hidden> 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.
>
> <sarcasm>Why not call it `\xyzzy` then?</sarcasm>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]