Adds tests for annotate, flatten, and parse_ion system macros #138
Conversation
| (then "from values that look like system values" | ||
| (text '''(:parse_ion "$ion_1_1 $ion_literal::$ion_symbol_table::{symbols:[]}")''') | ||
| (produces $ion_symbol_table::{symbols:[]})) |
There was a problem hiding this comment.
This seems dangerous because the expanded stream now has a system value. How do we prevent it from being interpreted as such on a subsequent roundtrip?
There was a problem hiding this comment.
Maybe it should still have $ion_literal on it, but the rules around $ion_literal still need to be cleared up. Does the $ion_literal annotation get silently dropped in the application reader before handing the value off the application/user, or does it stick around?
I don't think this problem is exclusive to parse_ion, though.
There was a problem hiding this comment.
I think it has to stick around, because not having it allows $ion_symbol_table to be the first annotation, which changes the semantics of the stream. Happy to punt on that though.
Co-authored-by: Tyler Gregg <[email protected]>
Issue #, if available:
#88
Description of changes:
annotate.flatten, which are almost identical tomake_sexpexcept for the macro name, macro address, and that the output is an uncontained stream rather than a s-expression.parse_ion. I took a stance that passing the wrong type of argument toparse_ionin TDL is a (macro) compile time error rather than an expansion error. Feel free to discuss/disagree.grammar.islto correct the capitalization of theannotkeyword for thedenotesexpectation.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.