An interesting observation: if you move the colon on the opposite side then you get valid EDN data!

{:one 1 :two 2 :array [a b c] :yes true}

cf. https://github.com/edn-format/edn

Likewise, commas are considered whitespace. They are sometimes added to make lengthy maps easier to read.

> Which is the same as the following JSON:

  {
    "one": 1,
    "two": 2,
    "array": ["a", "b", "c"],
    "yes": true
  }

That example also caught my attention, but in a bad way. It looks just like a comeback of one of the worst ideas of YAML.

My immediate question would be what's the JSON for this SEN I've crafted:

  {
    array: [string1 string2 "true" true True TRUE yes y]
  }

For more fun, there's a single problematic entry here, can you spot it?:

  1.20.4
  1.204.4
  1.20
  1.204
  1.20.0
  1.20.00
  1.20-rc2

Or, level expert, there's exactly one problem here as well:

  0a1f
  0bfd
  0c0c
  0d01
  0e02

Thank you for thinking more deeply about this than I did! But I do not see a problem in your first example, only true is the true true (according to my browser and the linked definition on https://www.json.org)

I don't get your other examples, can you explain? I assumed that 1.20.4 is not a valid SEN entry, because it starts with a digit but is not a number.

My bad, you are right about 1.20.4 (and also my 0e02 example wouldn't be a valid SEN value).

The true/"true" leaves a bad taste in my mouth after yaml, but overall SEN is an improvement :)

I'm not following: ` { array: [string1 string2 "true" true True TRUE yes y] } ` Doesn't look like a valid SEN or JSON. The `y` `yes`, `True`, TRUE` aren't valid keywords/variables/consts and `string1` and `string2` look like variable references which aren't something SEN or JSON support. The closest valid thing I can imagine is:

` { array: ["string1" "string2" "true" true "True" "TRUE" "yes" "y"] } `

aren't they implied strings? If "[a b c]" is an array of 3 strings, "a", "b" and "c", then True is a string "True". That's the problem.

I must be missing why you think they're implied strings - I don't see that in the spec. What I do see is:

"Strings can also be delimited with a single quote character which allows for a string to be either "abc" or 'abc'."

There's no mention of having a string without a delimeter.

The example below is this:

> array: [a b c]

ohhh I see it now, that looks like a recipe for... issues.

Let me guess: 0e02 is interpreted as floating point?

Ditto 1.20, and when interpreted as floating point the trailing zero loses significance. So as a version this is indistinguishable from 1.2

Am I missing something about the definition of “tokenStart”? It can be ‘letter’ or three other characters: but all those other characters (and more) are already in the definition of ‘letter’?

See the comment upthread about S-expressions, but .. given that this doesn't have a marker for "atom" which it badly needs, isn't it strictly worse than S-expressions.