There's a basic issue that could do with fixing re the single element list
Re auto inverse matching - maybe if key/value pairs were signalled by using triple nested lists instead of double nested e.g.
being mapped to {"item1":"item2"}
Then a double nested list could just return the simple JSON array ["item1","item2"]
But don't think a number or a string representation of a number would necessarily survive a round trip conversion and be returned in the same format it started off in
e.g
{"age":30} would be converted to list(list(list(age,30))) and then when converted back it could end up the same if Snap! checked if the value was valid numeric
But {"age":"30"} would also be converted to list(list(list(age,30))) and then when converted back it could end up as {"age":30} as Snap! would have no idea that the original 30 was a string
another problem with the csv format:
(3rd line is missing)
This time, the problem seems to come from the splitting block because:
(the result has 3 lines...)
(2 rows in the list)
the split block always skip the last empty record...
Oh stop it please! JSON is a key-value format used to communicate with web services. that's why we're using it, not as a generic universal data format.
But if a user puts a 3-D or higher list in a variable, and then clicks "export" on its watcher, Snap! writes a file called "data.json" that contains stuff that looks like JSON but without keys, just values. If you want to say we use JSON only for key-value situations, then we should find a different notation for 3-D lists, e.g., Lisp notation. Or, I don't care, Python notation! It's not about Lisp; it's about having a good export/import notation for deep lists.
On the other hand, as I remember it, we picked JSON because there's external software that knows how to read the text file and create a structured list from it. This approach works perfectly in the case of 2-D lists represented as csv, which is then readable by spreadsheet software as well as by Snap! ittself. Apparently it doesn't work perfectly using JSON for higher-dimensional lists.
After a workaround and with a bit of cheating: add 2 dummy rows at the end of each list in list before running the block "json of" and remove all of these dummy row after running the block "split by json"
Which is pretty much the same as Lisp notation, just with brackets instead of parentheses. (Unless you look at Python tuple notation, in which case it does use parentheses.)
? I see this as a good solution for now.
