-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"_" as a function head needs specification #457
Comments
To clarify some misunderstandings:
The spec currently states:
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:
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. |
I don't think English grammar is any help here. Even It's true that the general flexibility would allow I don't see how referencing the presentation tree can have any bearing on this. We can decide a default reading for I think the options are
I've got a mild preference for 1 as that is in the spirit of the 2 works I think but does make 3 is OK, and still keeps |
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 (
Framing everything in terms of a ":silent property" is a mistake in my eyes. If for some reason the prevailing sentiment is for |
@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
As can be seen by the current implementation |
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
The comma represents a pause in text, and is a simple argument separator in the intent syntax.
Yes, let's. |
sure, "comma", "and", translations of that, ... the point is by default something get said unless we specify otherwise.
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. |
we need to clarify the property list default in any case. If |
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 |
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. |
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:
Because there is nothing special about a head of 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 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, The second is a bug in the spec:
It should be |
Yes. An empty function head is only ever useful as a placeholder for concatenating the arguments. There is no The re-centering of the Intent text around these |
"intended use"? Maybe you were clever enough when we discussed allowable characters in a name to realize that I still haven't heard a reason why adding a special case for
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 Maybe @davidfarmer or @physikerwelt who are also looking to generate |
Basically you are arguing for option 2 above, have Currently as the spec is written Option 2 suggested changing that so uniquely I made a PR implementing option 3 so
although option 1
is OK and really I much prefer preserving the mathematical structure
so I don't see |
I was surprised to see the latest grammar allows 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, David C's last comment shows the other kind of artificial construct - |
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*.
|
Yes exactly. Either way I can't see that using a meaningless function name just to concatenate the arguments has any real But given Deyan strongly prefers See https://mathml-refresh.github.io/intent-lists/intent5.html#IDparallel for |
Yes.. I just recursed on |
Sure. That PR is nominally acceptable, I just don't like the way you've decided to anchor the feature set on 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:
|
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
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 I would hope by the end we can describe all these in a similar way to give a coherent description of the design.
yes, I know. I was going to hold off merging 458 until after you had posted your PR so that they could be compared |
I understand that Adding the words "is" and "to" seems like one of those places where things get |
@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
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&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> |
I'd agree with David F that 99 times out of 100 you shouldn't be forcing the
I would probably prefer to write it as
so the head of the term has some meaning if you drop the |
@physikerwelt what consumes the content mathml currently? Probably the same information could be encoded more compactly as
But that is only useful if it doesn't break everything. |
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:
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 So David C's reply should more accurately be even:
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
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 As to 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 |
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. |
SHA: b2f64d4 Reason: push, by davidcarlisle Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@NSoiffer asked what options I would likely use for non-core intents. I am pretty sure I will never use But I would be happy to look at examples if it seems I am missing the point. |
@davidfarmer wrote:
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"? |
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: ***@***.***>
|
I think (although mathcat doesn't always agree) you can use it to over-ride a core default. If |
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. |
I agree. |
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: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?
The text was updated successfully, but these errors were encountered: