nmushegian / jams Goto Github PK

JSON libraries manually handling escapes will check the character after a '' to make sure it is a valid escape, eg '\' '\r', '\n', '\t' '\b', or a valid unicode escape. This kind of escape handling passes the current JAMS test suite. However, you can also pass the tests by simply blindly including anything following a '\' inside a quote string, without checking for a valid escape. Opening issue to request clarification on how best to handle in JAMS.

i.e. similar to casetest, but without having to escape a bunch of stuff to make it work

We certainly want empty strings be part of the format.

• you can test all bareword pass cases with one test like { ok !@#$....}
• you need a distinct fail case for each bad bareword character maybe like { bad st[ring }
• you can test all pass cases for quoted strings with one test like { ok " ... " }, include all variations of all escapes and whitespace
• do quoted strings even have fail cases? If all undefined \ are defined to pass through, then you can't have an invalid string? at worst you terminate the string early with "?

Jams.js is not currently usable by default without either changing the import to point to the actual file jams.js / changing the filename of jams.js to index.js

To keep our sanity this time around let's try to stick with file-based tests as much as possible
For that we need a fail folder to correspond to pass folder where we put files that are supposed to fail to parse

It is important to make sure they are failing due to JAMS parse error and not some other reason, and that 'failing failures' are not squelched

Similar to #4

If a string uses unicode escape sequences, that sequence should be a well-formed code point (not necessarily defined in unicode table just valid bytes)

Duh

let’s also have a better interface than toJSON maybe put optional args into named opts

JSON spec does not say what to do if there are multiple keys and different parsers do different things.

In JAMS, duplicate keys are defined to be invalid JAMS files, they should not parse. Note this technically changes which kind of language/grammar JAMS is (not LL1 anymore I think) but it doesn’t matter

This will let us drop ebnf and also have comprehensible error messages
We might be able to dump the generated parser (function built at runtime) out of ebnf library somehow for guidance

"same as JSON, but allow newlines" (also tabs?)