improve StringForm implementation #1619
Conversation
mathics/builtin/numbers/calculus.py
Outdated
| + "`, `".join(list(methods)) | ||
| + "`}. Using `Automatic`" | ||
| + "built-in method name in {\\[RawBackquote]" | ||
| + "\\[RawBackquote], \\[RawBackquote]".join(list(methods)) |
There was a problem hiding this comment.
'' here are interpreted as placeholders in StringForm`. Use the named character instead.
This is great. Would it be possible to add some tests that demonstrate this? |
| # are parsed. | ||
| # "\\`" must be parsed as "\\`" in order this | ||
| # works properly, but the parser converts `\\` | ||
| # into `\`. |
There was a problem hiding this comment.
Are we talking about the Mathics3 scanner or the Mathics3 parser? (Both terms are used)
Can you provide an example using mathics3-tokens that compares against CodeTokenize?
(Perhaps before release, I will be getting the Mathics3 token names to agree more)
There was a problem hiding this comment.
Suppose you enter in the CLI
In[1]:="\\\`"
This is what happends in WMA:
In[1]:= A="\\\`"
Out[1]= \\`
In[2]:= StringTake[A,{1}]
Out[2]= \
In[3]:= StringTake[A,{2}]
Out[3]= \`
and this in Mathics:
In[1]:= A="\\\`"
Out[1]= "\\`"
In[2]:= StringTake[A,{1}]
Out[2]= "\"
In[3]:= StringTake[A,{2}]
Out[3]= "\"
In[4]:= StringTake[A,{3}]
Out[4]= "`"
The point is if I try to escape the backslash before a backquote chraracter, the result is a string with a (Python) value '`', so the backslash fails to be escaped. In some way is something marginal, and can be avoided by concatenating the strings. When I have a more close description, I am going to put an issue discussing this.
There was a problem hiding this comment.
Suppose you enter in the CLI
In[1]:="\\\`"This is what happends in WMA:
In[1]:= A="\\\`" Out[1]= \\` In[2]:= StringTake[A,{1}] Out[2]= \ In[3]:= StringTake[A,{2}] Out[3]= \`and this in Mathics:
In[1]:= A="\\\`" Out[1]= "\\`" In[2]:= StringTake[A,{1}] Out[2]= "\" In[3]:= StringTake[A,{2}] Out[3]= "\" In[4]:= StringTake[A,{3}] Out[4]= "`"The point is if I try to escape the backslash before a backquote chraracter, the result is a string with a (Python) value '`', so the backslash fails to be escaped. In some way is something marginal, and can be avoided by concatenating the strings. When I have a more close description, I am going to put an issue discussing this.
Ok. Thanks for the information. So the problem might not necessarily be in Mathics3's scanner. It might not even be in Mathics3's parser, either, but somewhere else, such as in boxing routines.
And when we know what's up, then we can decide whether to fix it or write workaround code as we have here. (Or maybe this is where the code should go.)
Let's mark this as a draft until the tests and a decision about how to handle this kind of thing are discussed.
BTW, in the back of my mind, when I mentioned going, moving from resolving InputForm to OutputForm, I had thought: there are probably a couple of smaller, simpler data forms that we could and probably should handle before OutputForm and which will probably feed into OutputForm.
I hesitated on that only because I sensed an anxiety to get OutputForm overhauled (along with the other general Forms like StandardForm). Rest assured, they will get done.
But there will be a lot less chaos if we start small and work our way up.
There was a problem hiding this comment.
Ok. Thanks for the information. So the problem might not necessarily be in Mathics3's scanner. It might not even be in Mathics3's parser, either, but somewhere else, such as in boxing routines.
And when we know what's up, then we can decide whether to fix it or write workaround code as we have here. (Or maybe this is where the code should go.)
Let's mark this as a draft until the tests and a decision about how to handle this kind of thing are discussed.
I think that fixing this issue with the escape sequences does not affect this PR: In the end, an expression of the form StringForm["... \\` ...", ...] would be a corner case. Right now, what is needed for the existing and foreseeable code is the ability to escape the backquote, which this PR handles. Tests for this were already added.
BTW, in the back of my mind, when I mentioned going, moving from resolving InputForm to OutputForm, I had thought: there are probably a couple of smaller, simpler data forms that we could and probably should handle before OutputForm and which will probably feed into OutputForm.
My reason to go over OutputForm is that it decouples the MakeBoxes processing from most of the other tests. I am close to cover all the cases to switch format_element to use it instead of the current format sequence.
I hesitated on that only because I sensed an anxiety to get OutputForm overhauled (along with the other general Forms like StandardForm). Rest assured, they will get done.
But this is happening along with the work with OutputForm: issues with these other special forms are coming up and handled as I check the new OutputForm routine against the existing code. In comparison, this PR is quite simple. When this PR gets merged, the next step would be to rework NumberForm, which seems to be a little more involved.
But there will be a lot less chaos if we start small and work our way up.
* avoid '<mo></mo>' in MathMLForm (empty string operator) * Fix error handing in eval_StringForm_MakeBoxes * Improve StringForm documentation
"<mo></mo>" cannot be parsed in Mathics-Django browser interface, so avoid to convert `""` into `<mo></mo>`.
* Documentation tested on Mathics-Django and LaTeX * ruff
|
@rocky, I guess now this is ready for review. Please check the docstring. |
Great! I'll look at Tuesday morning. |
Going over
mathics.builtin.forms, I realized that the current implementation ofStringFormhad some issues with poorly formed templates. The implementation now is slightly more robust and is located inmathics.eval.string.Fixing this, also come up some issues in the messages for
ContainsOnlyandNIntegrate, which are also handled here.