3 ms·

> There's no law that says you have to include everything in the quotation, right? Oh, if only languages worked so consistently. DESCRIPTION_OF_WHAT_WAS_SAI

> There's no law that says you have to include everything in the quotation, right? Oh, if only languages worked so consistently. DESCRIPTION_OF_WHAT_WAS_SAID: "$(DIRECT_QUOTE.)". Then again, in programming things don't always nest either, since sub shell calls have all sorts of oddities in regards to escape sequences. Has there ever been a case of anything nesting nicely, be it in languages, programming, or any other medium of writing? Maybe XML? I'm not sure.

maybeOneDay 5y ago
> Has there ever been a case of anything nesting nicely, be it in languages, programming, or any other medium of writing? Maybe XML? I'm not sure. JSON?
- KronisLV 5y ago
  Not quite, in practice you still occasionally stumble upon situations like these: https://stackoverflow.com/questions/51974631/how-do-i-properly-escape-double-quotes-in-strings-nested-in-a-json-object-locate https://stackoverflow.com/questions/51974631/how-do-i-proper... Or this: https://github.com/spaceghoul/json_deep_parse#example-usage-and-results https://github.com/spaceghoul/json_deep_parse#example-usage-...
  - maybeOneDay 5y ago
    I see what you mean, but the first appears to be a PHP bug (unless I am misreading?). The second, appears to be a tool for parsing a json blob which has been escaped and encoded as a simple string inside another json blob. That's certainly an interesting problem, and one that is likely to come up in a sufficiently complicated world - however it's not an issue with parsing JSON. It's an issue with parsing /any/ data structure or language that may contain strings and as such seems unavoidable.
    - KronisLV 5y ago
      > It's an issue with parsing /any/ data structure or language that may contain strings and as such seems unavoidable. Except for a data format which would allow embedding data in a nested fashion without altering it in any way. For example: some_object_field: "some value" some_other_field: with_sub_objects: and_sub_fields: "with values" and_also_fields: """ which_allow_objects: embedded_as_strings: "without transforming the structure" which_both: "JSON and XML" have_somewhat: "failed to do" #""" control sequences should also be valid in the body, as long as there is proper indentation, a la Python # which could then be simply stripped for display, for example, based on the first """ having N indentation # then it would follow that the rest of the data entries have N+TAB_WIDTH, which could be simply stripped # also, processing the beginning of every line would be less expensive than iterating through the entire line in search of escaped \n or anything of the sort """ Multi-line strings in JSON are also an embarrassment: https://stackoverflow.com/a/2392888 https://stackoverflow.com/a/2392888 As a consequence, the amount of parsing and processing that you need to do is really bad for performance. Of course, there are formats like YAML and TOML that go in the opposite direction - they try to cover all use cases and end up being overcomplicated. There are occasionally other attempts like JSON5 to improve things: https://json5.org/ https://json5.org/ However those also oftentimes are not very popular, because there is just too much ecosystem that has been built around the older formats, like XML, JSON and even YAML.
arethuza 5y ago
I guess that's what XML namespaces were supposed to allow. Reality seemed to involve eldritch abominations like one system I encountered that had entire Base64 encoded XML documents embedded as attribute values in a higher level document and then this approach applied recursively.... Edit: Of course, this wasn't XMLs fault - but for some reason a lot of XML used in the "enterprise" world seemed to be primarily designed to eat the soul of whoever gazed upon it.

maybeOneDay 5y ago

> Has there ever been a case of anything nesting nicely, be it in languages, programming, or any other medium of writing? Maybe XML? I'm not sure. JSON?

KronisLV 5y ago
Not quite, in practice you still occasionally stumble upon situations like these: https://stackoverflow.com/questions/51974631/how-do-i-properly-escape-double-quotes-in-strings-nested-in-a-json-object-locate https://stackoverflow.com/questions/51974631/how-do-i-proper... Or this: https://github.com/spaceghoul/json_deep_parse#example-usage-and-results https://github.com/spaceghoul/json_deep_parse#example-usage-...
- maybeOneDay 5y ago
  I see what you mean, but the first appears to be a PHP bug (unless I am misreading?). The second, appears to be a tool for parsing a json blob which has been escaped and encoded as a simple string inside another json blob. That's certainly an interesting problem, and one that is likely to come up in a sufficiently complicated world - however it's not an issue with parsing JSON. It's an issue with parsing /any/ data structure or language that may contain strings and as such seems unavoidable.
  - KronisLV 5y ago
    > It's an issue with parsing /any/ data structure or language that may contain strings and as such seems unavoidable. Except for a data format which would allow embedding data in a nested fashion without altering it in any way. For example: some_object_field: "some value" some_other_field: with_sub_objects: and_sub_fields: "with values" and_also_fields: """ which_allow_objects: embedded_as_strings: "without transforming the structure" which_both: "JSON and XML" have_somewhat: "failed to do" #""" control sequences should also be valid in the body, as long as there is proper indentation, a la Python # which could then be simply stripped for display, for example, based on the first """ having N indentation # then it would follow that the rest of the data entries have N+TAB_WIDTH, which could be simply stripped # also, processing the beginning of every line would be less expensive than iterating through the entire line in search of escaped \n or anything of the sort """ Multi-line strings in JSON are also an embarrassment: https://stackoverflow.com/a/2392888 https://stackoverflow.com/a/2392888 As a consequence, the amount of parsing and processing that you need to do is really bad for performance. Of course, there are formats like YAML and TOML that go in the opposite direction - they try to cover all use cases and end up being overcomplicated. There are occasionally other attempts like JSON5 to improve things: https://json5.org/ https://json5.org/ However those also oftentimes are not very popular, because there is just too much ecosystem that has been built around the older formats, like XML, JSON and even YAML.

arethuza 5y ago

I guess that's what XML namespaces were supposed to allow. Reality seemed to involve eldritch abominations like one system I encountered that had entire Base64 encoded XML documents embedded as attribute values in a higher level document and then this approach applied recursively.... Edit: Of course, this wasn't XMLs fault - but for some reason a lot of XML used in the "enterprise" world seemed to be primarily designed to eat the soul of whoever gazed upon it.