Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON5 Data Interchange Format

json5.org

Post reply on HN
Print view View original

141–150 of 157 posts

Re: JSON5 Data Interchange Format

#141

Post by krapp »

kybernetikos wrote: post #140
rbut wrote: post #19

Earlier quoted context omitted.

If you wanted JSON to parse into actual date objects, you could always do: { thisIsADate: new Date('1995-12-17T03:24:00Z') } It would be simple enough for parsers in other languages to parse this into their own date objects. Much simpler than using regexs to find ISO strings.

I think allowing a whitelisted set of constructors (so it's extensible, but with some standard ones) as types in a future JSON-like could be good. e.g. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like const seriali…

I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire.

I think all JSON needs in this regard is type hinting. Let everything else be handled by the application:

    {
      birthdayParty: Date 1632817436514,
      sounds: String? { // zomgwtfbbq comments too 
          cow:"moo",
          fox: null 
      },
      possibilities: ["she loves me", "she loves me not", 42],
      aSymbol: Symbol "tag",
      aBuffer: Uint8 [104, 101, 108, 108, 111]
    }

Re: JSON5 Data Interchange Format

#142

Post by phyrex »

kwhitefoot wrote: post #118
usrusr wrote: post #51

Earlier quoted context omitted.

An annoying half-solution that breaks down as soon as you encounter content with both. Better imho to have one way and become good at it. I think I might even prefer trailing commas to be mandatory.

Why does it need commas at all? What purpose do they serve?

They don’t serve one. Clojure uses only white space for distinguishing items in lists and hashmaps and after a short period of “this is weird” you embrace it and wonder why you ever needed commas at all

Re: JSON5 Data Interchange Format

#143

Post by kybernetikos »

krapp wrote: post #141
kybernetikos wrote: post #140

Earlier quoted context omitted.

I think allowing a whitelisted set of constructors (so it's extensible, but with some standard ones) as types in a future JSON-like could be good. e.g. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like const seriali…

I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire. I think all JSON needs in this regard is type hinting. Let everything else be handled by the application: { birthdayParty: Date 1632817436514, s…

I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function.

Obviously, in your version my approach would be

    sounds: Map {
        cow: "moo",
        fox: null
    },
    possibilities: Set ["she loves me", "she loves me not", 42]
I suppose that the idea could be that type hints are entirely ignoreable, and if you strip them the file just becomes normal JSON?

Re: JSON5 Data Interchange Format

#144

Post by keithalewis »

skowron wrote: post #99
jagger27 wrote: post #96

Earlier quoted context omitted.

This is why I like backticks. ` should almost never show up in normal English text.

And, luckily, all transmitted text is normal English.

If English was good enough for Jesus Christ it's good enough for me

Re: JSON5 Data Interchange Format

#145

Post by Rendello »

0xdeadb00f wrote: post #75
conradludgate wrote: post #64

Earlier quoted context omitted.

Rust has similar but it scales infinitely. They're called raw strings, "normal string can contain ' " r#" raw string can contain " ' "# r###" if for some reason you need to write "# "### Kinda like heredocs

Most (newer) programming languages have a concept of multi-line string literals.

My favourite variation is from Zig:

    const hello_world_in_c =
        \\#include 
        \\
        \\int main(int argc, char **argv) {
        \\    printf("hello world\n");
        \\    return 0;
        \\}
    ;
It neatly sidesteps the whole "cat-and-mouse" issue.

Pair this with the fact that it only has the C++ style // comments, it means that every line can be tokenized independently. Not that that particularly matters for programmers, but I know Vim sometimes gets confused about where Python's strings end and it turns the syntax highlighting to garbage.

Re: JSON5 Data Interchange Format

#146

Post by afiori »

Rendello wrote: post #145
0xdeadb00f wrote: post #75

Earlier quoted context omitted.

Most (newer) programming languages have a concept of multi-line string literals.

My favourite variation is from Zig: const hello_world_in_c = \\#include \\ \\int main(int argc, char **argv) { \\ printf("hello world\n"); \\ return 0; \\} ; It neatly sidesteps the whole "cat-and-mouse" issue. Pair this with the fact that it only has the C++ style // comments, it means that every line can be tokenized independently. Not that that particularly matters for programmers, but I know Vim sometimes gets co…

it also fixes the indentation problem

Re: JSON5 Data Interchange Format

#147

Post by usrusr »

staticassertion wrote: post #87
usrusr wrote: post #51

Earlier quoted context omitted.

An annoying half-solution that breaks down as soon as you encounter content with both. Better imho to have one way and become good at it. I think I might even prefer trailing commas to be mandatory.

It solves the problem like 99% of the time in my experience. It's very rare that I have content with both single and double quotes.

That's exactly my point: 99% solutions are the worst. Every 99% solution will eventually find someone relying on it, willingly or not. And it's always someone else cleaning up the mess (or failing to find the cause).

Re: JSON5 Data Interchange Format

#148

Post by kapep »

jagger27 wrote: post #119
skowron wrote: post #99

Earlier quoted context omitted.

And, luckily, all transmitted text is normal English.

I'd be interested to see a counter example where a standalone backtick is part of normal non-computing related text. I really don't find your comment helpful. The strings where I see single and double quotes being used most frequently is with normal, yes, English text. The backtick is useful there, and that's all I wanted to say. French doesn't really have the same issue, since guillemets (« and ») are often used in…

I think the point was that it doesn't make sense to expect that strings in a format like JSON or a programming language will only be used for non-computing related plain text.

Re: JSON5 Data Interchange Format

#149

Post by krapp »

kybernetikos wrote: post #143
krapp wrote: post #141

Earlier quoted context omitted.

I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire. I think all JSON needs in this regard is type hinting. Let everything else be handled by the application: { birthdayParty: Date 1632817436514, s…

I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function. Obviously, in your version my approach would be sounds: Map { cow: "moo", fox: null }, possibilities: Set ["…

I suppose my point was that you don't have to specify types for maps and sets at all (which I didn't do in my example,) the existing syntax already does that. [] is already a set, {} is already a map. Type hints would just be used for the values.

Sending type definitions seems like a good idea. Although at that point it might as well not even be called any kind of JSON.

Re: JSON5 Data Interchange Format

#150

Post by usrusr »

kwhitefoot wrote: post #118
usrusr wrote: post #51

Earlier quoted context omitted.

An annoying half-solution that breaks down as soon as you encounter content with both. Better imho to have one way and become good at it. I think I might even prefer trailing commas to be mandatory.

Why does it need commas at all? What purpose do they serve?

Checksums, basically, drawing a line between random bytes and structured JSON in a way that comes at zero cost for a human mind (arguably less than zero). We might as well leave out all closing tokens at the end of the stream, in a way those are completely redundant but still worth it for the warm, fuzzy feeling of knowing that you haven't just read a truncated stream.
Post reply on HN