"_" as a function head needs specification

[NSoiffer]

For a long time now, Deyan's favorite hack to the intent syntax was to have _(this_is_a_string_of, text) be read as "this is a string of text". This was an escape hatch to functional syntax that allows for a string of text. David sent me a bug report in some version of MathCAT's intent handling where it was read as "of this is a s string of comma text". Then he waffled saying maybe that is correct.

I initially thought it was a bug but looking back at the spec and what we say about _ standing alone, I think MathCAT got it right: this is a function call whose head is silent and has two children. Hence, that is a correct reading. As per the spec, the head is silent. In fact, the head is not a concept, but a literal:

Names starting with "_" (U+00F5) are always considered to be literal names, and should never be in an Intent Concept Dictionary.

My guess is that this escape hatch is considered desirable. If so, the spec needs modification to say this is an exception to the above statement. But first, I'd like to find out if people really want this escape hatch.

Note that we don't need this escape hatch because :silent(this_is_a_string_of, text) says 'ignore the head and just read the children'. Other alternatives include _:prefix(this_is_a_string_of, text), etc. So maybe we shouldn't complicate the spec?

Thoughts?

[dginev]

To clarify some misunderstandings:

1. "a string of text" is just a single literal, _this-is-a-string-of-text.
2. The single underscore function head _() was meant by me exactly as a way of co-opting the functional syntax, focused on providing a simple list of pieces, to be spoken in order without connectives
   • that is useful for mixfix notations. In these cases, there can be a mix of meaningful concepts and/or $reference pieces and/or literal text. As a new example:
     • choosing _($F,_is,left-adjoint,_to,$G) or _($G,_is,right-adjoint,_to,$F) for the exact same adjoint functors notation, written $F\dashv G$.
3. The decision for MathCAT to rigidly produce "of" and "comma" for the _ head case is a good example why systems that ignore expression context are at risk of producing ungrammatical English. To me "of this is a s string of comma text" is buggy output, assuming a system that aspires to generating English text (sorry).

The spec currently states:

An application denotes a function applied to arguments using a standard prefix notation.

That doesn't cover "of" and "comma", and how bravely systems should use them, I think?

One of my few contributions to the spec so far was the one example which anchors what I expect from the underscore at 5.1.5, quote:

_(free, _($r,algebra), on, $x)
would be read as "free r algebra; on x"

With that example in the spec, to my reading, we are discussing a system bug. If the text needs to be more explicit, that's a fair request.

[davidcarlisle]

The decision for MathCAT to rigidly produce "of" and "comma" for the _ head case is a good example why systems that ignore expression context are at risk of producing ungrammatical English.

I don't think English grammar is any help here. Even intent="f(a,b)" read as "f of a comma b" with comma voiced does not correspond to normal language grammar. Here specifially, use of literals are to over ride the usual speech. intent="english_bad_this_is should get read as that. Currently _works because of the general rule that _ should be treated as a space. As it starts with _ the spec says it is guaranteed not to be in core so should be treated as a literal.

It's true that the general flexibility would allow _(x,y) to be read as "x y" rather than "of x comma y" but even if Mathcat added a rule that did that, other implementations following the spec might not, so an author should still use _:silent(a,b) to make the intention clear.

I don't see how referencing the presentation tree can have any bearing on this. We can decide a default reading for _(free, _(r,algebra), on, x) without any reference to mathml at all.

I think the options are

1. keep the normative description as it is, and change the example to be _:silent(free, _:silent($r,algebra), on, $x)
2. say that with the exception of _ names starting _ are not in core, _ is in core and read as if silent
3. add after
   For [=literal=] names, the text generated from the function head SHOULD be read as specified in the property.
   something like:

   If none of these properties is used, the `function` property should be assumed unless the literal
   is silent (for example `_`)  in which case the `silent` property should be assumed.

I've got a mild preference for 1 as that is in the spirit of the _-or-template discussions that _( wasn't a "feature" so much as an ugly but unavoidable consequence of the general rules, which could be put to good effect in some cases.

2 works I think but does make _ a specific feature (and also would not apply to __( )

3 is OK, and still keeps_(... as working from some general rules, not a specific _ feature.

[dginev]

I don't think English grammar is any help here. Even intent="f(a,b)" read as "f of a comma b" with comma voiced does not correspond to normal language grammar. Here specifially, use of literals are to over ride the usual speech. intent="english_bad_this_is should get read as that.

Not how I see it. There is a difference between a user overriding the language string with ungrammatical text(= buggy user) and an AT system taking a reasonable annotation and producing ungrammatical text(= buggy system). There is also a scenario where the spec mandates generating ungrammatical text (= buggy spec), which would have been the case if we had text that required rigid phrasal patterns (<head> of <arg1> comma <arg2> comma ...).

_:silent is a non-starter for me, because it is obviously redundant. _ is silent, as it normalizes down to space. Systems should expect it, is all.

Framing everything in terms of a ":silent property" is a mistake in my eyes. If for some reason the prevailing sentiment is for _(arg1,arg2...) to always have broken narration in mainstream AT systems, it would be an aid for adopters to entirely drop it from the intent syntax. Although clearly I'd like to keep it unless we have something better.

[davidcarlisle]

@dginev I can't see how you envisage the logic you suggest being implemented. literals are read literally.

If you want a system to distinguish _(a,b) from _xxx(a,b) we need to specify that in the spec. Some vague expectation that a system should automatically assume "xxx of a comma b" is gramatical but "of a comma b" is not will not be enough.

_:silent is a non-starter for me, because it is obviously redundant. _ is silent, as it normalizes down to space.

As can be seen by the current implementation :silent is not redundant here at all. It does not just (redundantly) make _ silent, it affects the way the arguments are read, and that is what this issue is about. While you could (perhaps) argue a system should not add a leading of I can't see any general principle why the comma should not be voiced. If we want that, we need to specify it. As I say I'm OK with adding such a specification.

[dginev]

@dginev I can't see how you envisage the logic you suggest being implemented. literals are read literally.

Yes. And function applications are composed from their pieces.

Not using "of" as a lead of a noun phrase seems kind of basic - I'm surprised Neil made the error really. I had code avoiding this completely from intuition (without a spec, and without using underscore) back in 2020 (see here). I had intuited a small "concept dictionary" for entries voiced prefix, and those did not need the "of" connector word. As in minus(1) spoken "negative one" and not "negative of one".

I can't see any general principle why the comma should not be voiced

The comma represents a pause in text, and is a simple argument separator in the intent syntax. A hypothetical AT may want to leverage pauses of different lengths (or different connector words, such as "and", "also", "next", "argument-three x end-argument-three" etc). In such cases it will not use the literal "_comma" sound. It's also different in non-English narration: the Bulgarian word for comma is prohibitively long ("_запетайка") and would likely be unpleasant to hear repeated often. We use the connector "and" much more frequently, as it is a single letter ("_и").

If we want that, we need to specify it. As I say I'm OK with adding such a specification.

Yes, let's.

[davidcarlisle]

We use the connector "and" much more frequently, as it is a single letter

sure, "comma", "and", translations of that, ... the point is by default something get said unless we specify otherwise.

Yes, let's.

So option 3 above then, that seems OK to me.

[dginev]

So option 3 above then, that seems OK to me.

Not really. I should probably file a PR, since there is a cascade of clarifying changes I would enact to the current grammar. For starters I would be clarifying the "application" rule not the "property" entry. Will set some time aside for that this week.

[davidcarlisle]

we need to clarify the property list default in any case.

If _(acts by default as _:function( it certainly won't work as you want, so all that's really needed is to say the reading already described for :silent is used.

[dginev]

If (acts by default as :function( it certainly won't work as you want,

I won't repeat what I wrote above - the assumptions you are using here aren't ones I subscribe to. It can easily work as I want it to, and I've implemented as much in the past.

In my mental model _:function, _:prefix, _:postfix and _:infix produce the exact same narration outcomes, because _ is always the empty literal. The discussion about properties is off-topic/unrelated in that regard.

[davidcarlisle]

In my mental model :function, :prefix, :postfix and :infix produce the exact same narration outcomes, because _ is always the empty literal. The discussion about properties is off-topic/unrelated in that regard.

The current spec explicitly calls out that these properties affect the reading of the arguments and not just of the head. That is also what the only implementation does. So you could make some suggestions to re-do again how properties are handled but as things stand it is certainly on topic.

I suspect describing different reading styles in terms of properties is going to be useful in other contexts too, notably reading styles for mtable.

[NSoiffer]

As I said at the start, I'm not opposed to making a special case for heads that are silent because they have only "_"s and "-"s, but that special case needs to be called out. Because there is another way to accomplish what you want via ":silent", I think some strong justification is needed why this wart/special case is important to add.

As the spec is written "head(x, y)" should be spoken as:

• if it has :prefix -- head x y
• if it has:infix -- x head y
• if it has:postfix -- x y head
• if it has :silent -- x y
• if it has :function -- some functional reading such as "head of x comma y" or "head of x and y"

Because there is nothing special about a head of _ or ____ or _----_ or ...: the head is not spoken. This means prefix/infix/postfix/silent all have the same reading, but not function because you need to call out (make distinguishable) the arguments.

The spec is silent on a default for which of those readings (prefix, etc) should be done for non-core intents when no airity property is given, and maybe that's where you (Deyan) have the disagreement as to what should happen? If someone wrote _:function(a,b) would you expect it speak as "a b" as you expect _(a, b) to be spoken?

In addition to potentially making a specific spec change for empty function heads, I see two other changes to the spec. The first is I think we should say that if no airity property is given, :function should be assumed for non-core intents, although maybe Deyan doesn't like that (see above).

The second is a bug in the spec:

An intent union :prefix ($a,$b) would indicate that the latter style is preferred.

It should be union:function($a, $b) to correspond with the reading.

[dginev]

If someone wrote :function(a,b) would you expect it speak as "a b" as you expect (a, b) to be spoken?

Yes. An empty function head is only ever useful as a placeholder for concatenating the arguments. There is no silent function of .... I would prefer to specify a unique/consistent behavior for _ irrespective of what :properties it has. And ideally it never has properties - they are off-topic to its intended use.

The re-centering of the Intent text around these :fixity annotations is rather off-putting to me. I see them as artificial special case constructs that I don't need. I'd much rather use an underscore head and control the exact order of the narrated pieces, in the few cases that require an override from the baseline narration.

[NSoiffer]

I would prefer to specify a unique/consistent behavior for _ irrespective of what :properties it has. And ideally it never has properties - they are off-topic to its intended use.

"intended use"? Maybe you were clever enough when we discussed allowable characters in a name to realize that _ (and all of its non speech variants) could be used to avoid a having a function head. It didn't occur to me until you pointed it out (a long while back). The spec has an example, but the lack of spec text for special casing it means that MathCAT didn't add a special case for it until David pointed out the bug. And my MathCAT special case won't work for __-_-_ and friends because I didn't think about them until mentioned earlier in this thread. I suspect others will also make that mistake (a chance for you to brag that you handle those correctly ;-). My view is that _ is more of an unintended consequence of wanting to have a way of saying "this is a literal, not a concept name" than a design goal for an empty head.

I still haven't heard a reason why adding a special case for _(a,b) is preferable to :silent(a,b) which does not require a special case other than that you don't want to use fixity properties.

The re-centering of the Intent text around these :fixity annotations is rather off-putting to me. I see them as artificial special case constructs that I don't need. I'd much rather use an underscore head and control the exact order of the narrated pieces, in the few cases that require an override from the baseline narration.

You may not need them or want to use them, but as I indicated in whatever issue it was where I first brought up their need, they are essential to a sensible reading of non-core intents in many cases unless one falls back to a textual reading... something the group agreed should not be encouraged. I completely agree that the limited list we have won't cover all cases (we probably should add Matchfix), but they cover a lot of common cases and thereby provide a way to avoid using template-like speech which will likely have accessibility problems (lack of appropriate being/end, etc). David's intent examples has many examples where they are useful; I'd hate to see them forced to use template-like speech.

Maybe @davidfarmer or @physikerwelt who are also looking to generate intents can chime in and say whether they would use silent, infix, etc., for non core intents when they don't want a non-functional reading of the intent or whether they would find any empty head better.

[davidcarlisle]

@dginev

I would prefer to specify a unique/consistent behavior for _

Basically you are arguing for option 2 above, have _ in core. Then it could have specific rules. As I said above that works but is my least favoured option.

Currently as the spec is written _ isn't a defined function, it is just a conveniently small and naturally silent name, The only thing the spec says about it, other than its use in examples, is that as a name starting _ it is guaranteed not to be known to the application, and will be treated as a literal.

Option 2 suggested changing that so uniquely _ is a known function with specific speech rules.

I made a PR implementing option 3 so

_(free, $r, _algebra_on, $x) works

although option 1

_:silent(free, $r, _algebra_on, $x)

is OK and really I much prefer preserving the mathematical structure

free-algebra:silent(_free, $r, _algebra_on, $x)

so I don't see _ as anything that needs special handling in the spec, although option 3, as in the PR, is OK.

[dginev]

I still haven't heard a reason why adding a special case for _(a,b) is preferable to :silent(a,b)

I was surprised to see the latest grammar allows :silent(a,b) which I think should be made ungrammatical. If it was grammatical it would imply there is an empty string - or an outer context - that it is annotating as silent, while taking arguments (a,b). To me this reads as if (a,b) are arguments of :silent, and currently properties don't have arguments. And if they did, why would :silent take arguments?

The reason I don't want to use fixity hints is exactly because they are an under-developed set of artifacts that fit a very limited set of cases. I have very little in common with the design intuitions being floated for how you use hints, while I think we can all agree on the templated pieces needed to write down "a" and "b". (it's "a" and "b")

Since every second comment here says the other commenters are OK with using the underscore, I suspect we can flesh that out and be done here. If not, :fixity isn't even my next choice - that would be another bracketing pair. [a b] is still much more intuitive than :silent(a,b) and likely easier to get used to than _(a,b). But it will add needless overhead to the intent grammar, which the underscore avoids.

---

David C's last comment shows the other kind of artificial construct - free-algebra:silent(...) is an artifact, because the free algebra is very much voiced in that example, not silent, it's just using a special narration pattern. The :silent head really means "if this were a symbolic content form, its head would be free-algebra, but ignore that when narrating", which may or may not be useful for applications different from accessibility. Making that mandatory is an "undue burden" for remediators, to me at least.

[brucemiller]

I was surprised to see the latest grammar allows |:silent(a,b)| which I think should be made ungrammatical. If it was grammatical it would imply there is an empty string

Actually, that's exactly the way I interpret it: the :silent applies to the function head, which is otherwise unspecified and so is empty. In that sense, it is somewhat redundant, but seems to me completely reasonable. I'd be fine with the spec saying that empty terms like "_" are treated the same as if :silent were given.

The reason I don't want to use fixity hints is exactly because they are an under-developed set of artifacts that fit a very limited set of cases.

No more or less than "" is an underdeveloped set of artifacts. These discussions are exactly for the purpose of developing them both, and clarifying. :silent "taking arguments" is no more or less weird than "" taking arguments, nor is making an exception that sometimes they aren't really "arguments" (for both :silent or "_").

Any weirdness of :silent doesn't eliminate the usefulness of fixity properties in other cases. I still find "foo:infix($a,$b)" vastly preferable to "_($a,foo,$b)", although I feel no compulsion to outlaw the latter.

Re: "free-algebra:silent(...)"

Making that mandatory is an "undue burden" for remediators, to me at least.

I understood the example to have been preferred not mandatory.

[davidcarlisle]

Re: "free-algebra:silent(...)" Making that mandatory is an "undue burden" for remediators, to me at least. I understood the example to have been preferred not mandatory.

Yes exactly. _:silent( would certainly be allowed even if we decided not to give _( that property.

Either way I can't see that using a meaningless function name just to concatenate the arguments has any real advantage over using a different silent head such as free-algebra:silent( which has the same effect as _( on the generated speech, but, to me looks nicer. But nothing mandatory, _( (if the PR is merged) or _:silent( or rabbit:silent( would be equally valid.

But given Deyan strongly prefers _( and Neil has added this back to Mathcat I suggest we don't argue about it, and merge #458 so that the spec is brought in to line, and move on.

See

https://mathml-refresh.github.io/intent-lists/intent5.html#IDparallel

for _( working with and without :silent with the latest mathcat (yesterday only the one with :silent worked)

[davidcarlisle]

I was surprised to see the latest grammar allows :silent(a,b) which I think should be made ungrammatical.

Yes.. I just recursed on intent for a function head to allow experimentation, especially as allowing argref or application as head were debated in other issues. But it is not at all impossible that that ends up with no useful interpretation and so should be removed. Probably best in (yet another) intent issue.

[dginev]

I suggest we don't argue about it, and merge https://github.com/w3c/mathml/pull/458 so that the spec is brought in to line, and move on.

Sure. That PR is nominally acceptable, I just don't like the way you've decided to anchor the feature set on :fixity behaviors.

I am working on an alternative PR, with a sadly larger diff which shows a variation on the various emphases that I consider more aligned with my mental model.

I'll add my new example there too:

choosing _($F,_is,left-adjoint,_to,$G) or _($G,_is,right-adjoint,_to,$F) for the exact same adjoint functors notation, written $F \dashv G$

[davidcarlisle]

I just don't like the way you've decided to anchor the feature set on :fixity behaviors.

Yes, I know:-), but they make for a coherent description and at least for mathcat, they align with the implementation, just giving names to the speech styles it has.

Same with tables. Until yesterday mathcat had various ways of reading an mtable but they were hard to describe and imposible to control, it would just "guess" one. But the latest build has named properties for each style and you can use

<mtable intent=":cases">

to say which style you want. The system still has full freedom over what words it uses.

The fixity hints are exactly the same, AT can use whatever words it wants but :infix gives it a hint on what style to use.

I would hope by the end we can describe all these in a similar way to give a coherent description of the design.

I am working on an alternative PR,

yes, I know. I was going to hold off merging 458 until after you had posted your PR so that they could be compared but I could merge it then you make a pr from there? Whichever you prefer.

[davidfarmer]

I understand that $F \dashv G$ can either be read "F is a left adjoint to G" or "G is a right adjoint to F". The first can be accomplished by intent="left-adjoint" on the \dashv. The second can be done with a surrounding mrow with (assuming I have followed where people are going) intent="right-adjoint:infix($g,$f)".

Adding the words "is" and "to" seems like one of those places where things get worse as often as they get better. But if it really matters (not my area, so I cannot say in this case), the intents could be is-left-adjoint-to or is-right-adjoint-to, depending on which markup the remediator chooses.

[physikerwelt]

@NSoiffer I got lost in the details of the intent grammar discussion. I guess in the first place we would generate content MathML and look for a downstream application that can serialize content MathML to intent. In addition, we consider adding an intent attribute on the formula level that is put 1:1 to the HTML. So when one has the following wikitext element

<math display=block qid=Q204819 id=euler intent="somevalue">e^{i\pi}+1=0</math>

This should generate

<math class="mwe-math-element" id="euler" display="block" xmlns="http://www.w3.org/1998/Math/MathML" href="/w/index.php?title=Special:MathWikibase&amp;qid=Q204819" intent="somevalue"><mstyle scriptlevel="0" displaystyle="true"><msup>
<semantics>
  <mi>e</mi>
  <annotation-xml encoding="MathML-Content"><csymbol cd="wikidata">Q82435</csymbol></annotation>
</semantics>
<mrow data-mjx-texclass="ORD">
<semantics>
  <mi>i</mi>
   <annotation-xml encoding="MathML-Content"><csymbol cd="wikidata">Q193796</csymbol></annotation>
</semantics>
<mi>π</mi></mrow></msup><mo>+</mo><mn>1</mn><mo>=</mo><mn>0</mn></mstyle></math>

[davidcarlisle]

I'd agree with David F that 99 times out of 100 you shouldn't be forcing the from and to but if I really needed

_($F,_is,left-adjoint,_to,$G)

I would probably prefer to write it as

left-adjoint:silent($F,_is_left-adjoint_to,$G)

so the head of the term has some meaning if you drop the _ prefixed literals (allowing a much simpler way of getting a semantic tree than the proposal in the github-pages document)

[davidcarlisle]

@physikerwelt what consumes the content mathml currently? Probably the same information could be encoded more compactly as

<math class="mwe-math-element" id="euler" display="block" xmlns="http://www.w3.org/1998/Math/MathML" href="/w/index.php?title=Special:MathWikibase&amp;qid=Q204819" >
 <msup>
  <mi intent=":wikidata-Q8243522">e</mi>
  <mrow>
  <mi intent=":wikidata-Q193796">i</mi>
  <mi>π</mi>
  </mrow>  
 </msup>
 <mo>+</mo><mn>1</mn><mo>=</mo><mn>0</mn>
</math>

But that is only useful if it doesn't break everything.

[dginev]

@davidfarmer @davidcarlisle

actually (not my field either, but I read the wiki article and had one lecture in grad school that touched on this)

The mathematical concepts "left-adjoint" (brief from "left-adjoint-functor") and "right-adjoint" (brief from "right-adjoint-functor") apply to "F" and "G", and not to the "⊣" notation. The operation here is "adjunction", where the argument convention is left-right.

This is a great Open example I think, since we shouldn't expect AT to cover this for any notion of soon. But to argue the case, if it were in Core, it would likely need to be marked up:

<mrow intent="adjunction($f,$g)"> ... </mrow> or indeed <mo intent="adjunction">&#x22A3;</mo>.

And (if it were in Core) we'd expect AT to choose the right speech, including the "in" and "to" connectives. If AT isn't familiar with the operation, it would likely narrate "F adjunction G" - which can be reasonably argued is a clear upgrade over "F Left Tack G".

Next, in that vein of argument, if we wanted to choose which side to emphasize while narrating, one would probably invent a new pair of artifacts :left and :right and do adjunction:left to speak "F is left adjoint to G" and adjunction:right to speak "G is right adjoint to F". (if this feels like handling a special case, that's exactly the point I am trying to illustrate)

So David C's reply should more accurately be even:

intent="adjunction:left:silent($F,_is-left-adjoint-to,$G)"
intent="adjunction:right:silent($G,_is-right-adjoint-to,$F)"

intent="adjunction:left:silent($F,_е-ляво-присъединен-към,$G)"
intent="adjunction:right:silent($G,_е-дясно-присъединен-към,$F)"

The only reason I see to do this extra verbose setup myself is to include international speech while anchoring to a symbol in some dictionary, i.e. to generate both accessibility and a Content form.

But for any remediation that only focuses on accessibility, that is a lot of optional markup weight that can be shed via _:

intent="_($F,_is-left-adjoint-to,$G)"
intent="_($G,_is-right-adjoint-to,$F)"

intent="_($F,_е-ляво-присъединен-към,$G)"
intent="_($G,_е-дясно-присъединен-към,$F)"

Thank you for following-up, helped me notice that my use of "left-adjoint" and "right-adjoint" didn't accomplish the right Content form at all, so they should have been kept with underscores. and between _is,_left-adjoint,_to, and _is-left-adjoint-to the single literal seems easier to read/write.

As to is-left-adjoint-to@infix($F,$G) - certainly it can be made to work, but to me it is more artificial than the alternatives. If a language override looks like a language override, the contrast helps to separate such uses of Intent from the "concept" uses of Intent.

Edit: rushed my examples a little - $F and $G have switched order when switching left/right, which is something that I didn't enact in the markup. That is why :left and :right are needed to figure out which argument is which in the Content tree.

[physikerwelt]

@physikerwelt what consumes the content mathml currently?

We have not yet released this. I was under the impression that the main goal of intent would be speech. So I guess depending on the language version we would rather use the labels for intents. So instead of

  <mi intent=":wikidata-Q824352">e</mi>

I would want to output (if nobody specifies the intent attribute manually)

  <mi intent="Euler's number">e</mi>

or

  <mi intent="eulersche Zahl">e</mi>

In french the intent would be only "e" as this is the french label in wikidata https://www.wikidata.org/wiki/Q82435

The content MathML could be used for search and calculations. Moreover, it could be transformed into RDF for further downstream applications (e.g., https://kwarc.info/teaching/CICM21WS/om2.pdf)

PS: Speaking about RDF. Wikidata also claims that Q824352 is the same as nums1#e

PPS: I have the feeling that this is, however, a different topic. However, I still want to model semantics and not only speech.

[davidfarmer]

@NSoiffer asked what options I would likely use for non-core intents.

I am pretty sure I will never use :silent. Probably I will not use any connector words either.

But I would be happy to look at examples if it seems I am missing the point.

[NSoiffer]

@davidfarmer wrote:

I am pretty sure I will never use :silent. Probably I will not use any connector words either.

Do you think you would use the other syntax hints ("prefix", "infix", "postfix", "function") to guide the reading of a non-core function? E.g., using "postfix" get something to read as "x star" rather than "star of x"?

[davidfarmer]

Yes, I can see using "prefix", "infix", and "postfix". I see these as useful on the surrounding mrow, as in intent="choose:infix($a,$b)", if binomial were not in core.

Will "function" be the default, in which case it is not needed: the "prefix" property stops the saying of "of". If I just put it first and use functional notation, I will hear "of", unless I include "prefix"?

All the examples that come to mind for "prefix", "infix", and "postfix" occur in a surrounding element (maybe mrow, maybe msup, or mover) and take named arguments. But I would be happy to know of other natural examples (which maybe were discussed and I am not recalling).

@davidfarmer wrote:

  I am pretty sure I will never use :silent. Probably I will not use any connector words either.

Do you think you would use the other syntax hints ("prefix", "infix", "postfix", "function") to guide the reading of a non-core function? E.g., using "postfix" get something to read as "x star" rather than "star of x"?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you werementioned.[AABTULCRWEEWHGH5KZROOHTW7WLA7A5CNFSM6AAAAAAWP6QIVOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSZIYP2W.g if] Message ID: @.***>

[davidcarlisle]

@davidfarmer

Will "function" be the default, in which case it is not needed:

I think (although mathcat doesn't always agree) you can use it to over-ride a core default.

If factorial is core and postfix by default,factorial(x) is x factorial and factorial:function(x) is factorial of x

[NSoiffer]

I think (although mathcat doesn't always agree) you can use it to over-ride a core default.

I need to go through the MathCAT rules and add a condition on when they trigger based on the properties they support if we argee that is appropriate. This is related to #435 which is focused on # of args, but is equally relevant to properties and maybe the object arguments.

[davidcarlisle]

I think this can be closed as #458 was merged specifically to add text for the (original) issue here. @NSoiffer ?

[NSoiffer]

I agree.