Conversation
Handle unicode for boxing operators inside strings.
and add more tests. Check more argument counts on some builtin functions.
* Add argument error-check test. * Add test to ensure an escape character is treated like one character.
0f1d580 to
e52afbe
Compare
9c8df99 to
317b90f
Compare
317b90f to
bc42ee9
Compare
mathics/format/form/outputform.py
Outdated
| strform_str = safe_backquotes(strform.value) | ||
| strform_str = safe_backquotes(replace_box_unicode_with_ascii(strform.value)) | ||
| parts = strform_str.split("`") | ||
| # Rocky: This looks like a hack to me: is it needed? |
There was a problem hiding this comment.
Indeed, it is a hack, to allow escape from the backquote. Maybe with the last changes in the scanner, it is no longer needed.
There was a problem hiding this comment.
Looks like we still need in order to make:
>> StringForm["`` is Global\\`a", a]
= a is Global`a
work. It might require a further change in the scanner. Or maybe there is something deeper here; a better change to StringForm is needed?
Either way, it's something that requires more thought, and since this stuff is already too large for a single change, I'd like to get this down and come back to this.
There was a problem hiding this comment.
Thanks for check this. We can look again in another round
There was a problem hiding this comment.
Thanks for check this. We can look again in another round
Teamwork!
test/builtin/test_strings.py
Outdated
| # These tests are commented out due to the bug reported in issue #906 | ||
| # Octal and hexadecimal notation works alone, but fails | ||
| # as a part of another expression. For example, | ||
| # F[\.78\.79\.7A] or "\.78\.79\.7A" produces a syntax error in Mathics. |
There was a problem hiding this comment.
I do not see this fail in master, and the previous version of Mathics-Scanner. Maybe this is a new bug? Now all these tests passes without problem.
There was a problem hiding this comment.
Thanks for checking. Tests reinstated now.
test/builtin/test_strings.py
Outdated
| "StringTake[abc, {0, 0}]", | ||
| None, | ||
| ), | ||
| # These tests are commented out due to the bug reported in issue #906 |
There was a problem hiding this comment.
I checked with this version, and the commented tests seem to pass without problems
There was a problem hiding this comment.
Thanks for investigating and reporting back. Reinstated now.
remove unneeded duplicate code in eval_StringForm_MakeBoxes
9121c63 to
9f9ca46
Compare
|
I'd like to mention something related to this change. In the past, there was a thought that all operators had to be represented by Unicode symbols. (This kind of thing was last done circa tokenized Basic in the mid 1970s.) This is not that. Here, we are doing this only for Box Expression "operators" (where grouping is also treated as an "operator"). And even then, only inside strings. To my mind, the thing that justifies this is the behavior of Exactly why it is that these functions work in this behavior is not readily apparent to me. I am sure there was some reason for this. But still, it feels like more of a hack than a fundamental principle. And even here, WMA was, I think, careful to restrict this Unicode character idea to the private-use section of Unicode. |
Handle boxing escape characters inside a string, in built-in functions
Characters,StringLength,StringTake, andToCharacterCode.Tracks API changes in MathicsScanner,
so must be merged not before Mathics3/mathics-scanner#152.Fixes #1622