Re: \consists terminology

[David Kastrup]

Flaming Hakama by Elaine <address@hidden> writes:

> On Fri, Jun 15, 2018, 1:42 AM David Kastrup <address@hidden> wrote:
>
>> David Kastrup <address@hidden> writes:
>>
>> > Flaming Hakama by Elaine <address@hidden> 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