Consider HJSON about ron HOT 9 CLOSED

My general feeling is that HJSON tried to patch the holes of JSON. It succeeded in it, but the main problem of lost semantics is still there (heterogeneous lists? really?)

from ron.

A few things out of the front page:

• white-space sensitive (optional commas)
• optional non-quoted strings

from ron.

white-space sensitive (optional commas)

Guh frick I hate white-space sensitive config files, please no... They've caused so many issues (for end users they mess up whitespace sensitive files significantly more than anything else I've ever seen)...

/me is still a fan of the HOCON format

from ron.

HOCON does the same with patching usability holes in JSON and does it in a much better way from what I'm reading, but honestly I'd probably add a few more special things to it's format, including:

{| ObjectType,
  blah: 42,
  bloop: 16,
}
// Is basically:
{
  _type: ObjectType,
  blah: 42,
  bloop: 16,
}

Basically being able to define the type of the object straight (in such a way that it keeps the max 2 character standard lookahead that the HOCON spec defines). And perhaps also a similar thing for homogeneous arrays:

// Where `int32` or so is a built-in type, maybe restrict usertypes to start with upper-case
// and reserve ones starting with lowercase as built-in standard types?
[| int32,
  42,
  16,
]
// Is basically:
[
  42,
  16,
]

// And this as another example:
[| ObjectType,
  {| ObjectType, blah: 42, bloop: 16},
  {| ObjectType, blah: 16, bloop: 42},
]
// Is basically:
[
  {_type: ObjectType, blah: 42, bloop: 16},
  {_type: ObjectType, blah: 16, bloop: 42},
]

And since the HOCON format can both take in and output text (comments and all) then it can always output the 'typed' format, which is fantastic for both parsing (pre-allocating the memory for a given known object type) and for documentation purposes (plus you could even leave out certain keys for an object type if they are optional).

from ron.

@OvermindDL1 err. This is all great, but should really go into the HOCON issue, not here.
See #6

from ron.

Heh, right, will move it there.

from ron.

The problem with HOCON is that it allows very complex features which e.g. require parsing everything to maps first.

from ron.

The problem with HOCON is that it allows very complex features which e.g. require parsing everything to maps first.

Not with my extensions it would not. I was thinking about those for a few hours yesterday and those extensions seem to solve those issues. :-)

On the code side you just specify the 'schema' (what types are expected where) and you verify it against the user input during parsing, parsing straight into those structures, no intermediary maps needed then. :-)

from ron.

Closing alternative issues and listing them in the wiki page.

from ron.