Re: New JSON Parser

In regard to determining what content might be valid, my best resource
appears to be the diagrams at http://www.json.org. For example, upon
encountering an open brace "{" I call a procedure named parse_object().
That procedure expects the following tokens:

- close brace (indicating the end of the object),
- double quote (indicating the begging of a name-value pair)
- colon (indicating the separator between a name-value pair),
- comma (indicating another name-value pair),
- whitespace (characters that can be discarded).

parse_object() subsequently makes calls to parse_name(), or parse_value(),
or parse_array(), or a recursive call to parse_object() upon encountering
their respective "opening" tokens. Each of those procedures implement
character checks using the diagrams at http://www.json.org.

In regard to the unexpected colon in Jon's example, I agree that should
have been handled differently. I made a change to leave (exit) the
parse_array() procedure consequently. This is a work in process. I'm
grateful for the input.



On Mon, Jul 27, 2020 at 12:03 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Mon, Jul 27, 2020 at 1:32 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

My inclination is to always return a meaningful reference regardless of
unexpected characters found in the stream, so that any valid content can

be

extracted or reported. That's my idea of error forgiveness.

That's a principle that you're trying to operate under, which seems
fine, but it doesn't say much about how you determine what content is
"valid" in the face of malformed input.

One thing that I think most of us could imagine is that everything is
considered valid until you encounter an unexpected character, and once
that happens, the rest of the input is ignored. If you haven't stopped
at a "convenient" place, then you discard whatever it is you were in
the middle of parsing until you do get back to a convenient stopping
place, and from there, you effectively close whatever open brackets
you have outstanding.

In the case of Jon's example:

[ "name" : X , "another" : 12 ]

The colon character encountered in position 9 would not be expected.

Right, and so it's weird that he wound up with a node with a value of
X, because X is past the unexpected character. How/why did the parser
pick up the X, and why would it be considered the next element after
"name"?

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com