I currently have the parser to find them and convent them to ' and _ style strings. Would it be hard to have retro perform this? Adding support for JSON style \ escape sequences would also be a nice to have.
You could create an alias for the ' prefix by doing:
:prefix:" |prefix:' ; immediate
For escape sequences, pass the string through s:format to process them. This supports:
| \r | Replace with a CR | | \n | Replace with a LF | | \t | Replace with a TAB | | \\ | Replace with a single \ | | \ | Replace with an underscore (_) | | \0 | Replace with NUL | | \^ | Replace with ESC | | %c | Replace with a character on the stack | | %s | Replace with a string on the stack | | %n | Replace with the next number on the stack |
If you want strings with embedded spaces, that would be considerably more difficult.
We would need an extended version of the
interpretword that could identify the starting and ending token, and maintain an internal state on the token type and manage appending to a temporary string as it's being built...
You can try this: http://forth.works/share/62a01f6d044f00b2b1214434ad7fb7cb
Thanks, thats a nice example of how to enhance the interpret function.
The upper layer removes multiple spaces so that is going to produce incorrect results for some strings :(
This could be worked around by moving the line parsing into retro and re-jigging the interpreter process more.
I am also plotting to support """ triple quote strings which would need state kept over multiple lines.
Is supporting double quote strings in retrocore something you would consider for 2021.4?
That is indeed an issue with this.
A better solution would be to write a new interpreter that has support for parsing input as opposed to handling individual tokens. This would change some aspects of Retro's behavior, but might be worth doing as an option. (I'm not changing the core interpret behavior, though I am quite willing to include and support more flexible interpreter as an option)
This will not be implemented in the core. Arland is looking at doing this in a modified interpreter, but we don't currently have a timeframe for this. Closing the issue for now.