seagreen

> The religious focus on purity. The elm maintainer is an haskell user, and it shows. Can you believe that to read the current time or generate a random number, you must be within a component's update function, ask for one or the other and you will get your result later, asynchronously?

You say this like generating a random number is a small deal. In a sense this is very true! From the machine's perspective generating a random number is a quick operation. However, from the perspective of maintainers who come after you losing determinism is no small thing, and IMHO deserves to be marked clearly in the type system.

Could you help clarify this? My guess is that you're saying that you have some data type with (eg) strings and timestamps. When encoded to binary these are encoded differently, resulting in hash A. But if you roundtrip the data through JSON first both come back as strings, which when encoded to binary gives hash B. Am I on the right track?

Have you seen my Son project? (https://github.com/seagreen/Son) I think I may have gotten JSON canonicalization right.

Also, I'm collecting a list of all subsets of JSON here if anyone knows of more: https://housejeffries.com/page/7

EDIT: Wow there's a lot of criticism in this thread. For the record I think TJSON is great.

First: XML is a markup language for encoding documents, JSON is a data-interchange language. Each can be twisted to do the job of the other, but they don't naturally do the same job.

Second, XML is extraordinarily complicated. Flipping around the XML 1.0 spec (https://www.w3.org/TR/xml/) isn't really encouraging me that all of this is there for a reason. I'd love to be proved wrong though!

In contrast, RFC 7159 is incredibly short and readable: https://tools.ietf.org/html/rfc7159. The TJSON spec isn't bad either: https://www.tjson.org/spec/. Even combining both the result is still far shorter and more clear than XML.

I should have written libre not free. That has a clear meaning (and it's what I use in the followup comment). Do you have a better suggestion than "open" for "no restrictions on use"?

> Personally, if I'm writing a hobby project then I want it to be copyleft.

Totally up to you! In the context of Haskell projects though, I really, really want to see Haskell businesses succeed as well as the open Haskell ecosystem.

I understood you! I just wanted to add a few reasons why I (generally an open > libre guy) don't mind the AGPL in this case.

Weirdly I think free licenses are great for businesses to use and open licenses are great for personal projects.

If I'm writing a hobby project, I want it to help the ecosystem as much as possible. If businesses want to use it then great! So MIT.

If I'm running a business my main goal is to survive. I want to help the community as well, but I obviously can't do that if I go broke. "Put on your own oxygen mask before helping others" and all that. So *GPL, because it lets me balance those goals.

I read this comment before looking at the site, but I still wasn't expecting that. It's bad.

SUDEP is a thing. Come on people: https://en.wikipedia.org/wiki/Sudden_unexpected_death_in_epi...

" When OpenAI launched, it characterized the nature of the risks - and the most appropriate strategies for reducing them - in a way that we disagreed with. In particular, it emphasized the importance of distributing AI broadly; our current view is that this may turn out to be a promising strategy for reducing potential risks, but that the opposite may also turn out to be true (for example, if it ends up being important for institutions to keep some major breakthroughs secure to prevent misuse and/or to prevent accidents). Since then, OpenAI has put out more recent content consistent with the latter view, and we are no longer aware of any clear disagreements. "

Really, really happy to see this being carefully considered. Good job to the Open Philanthropy folks!

EDIT: That Slate Star link is amazing: "Both sides here keep talking about who is going to “use” the superhuman intelligence a billion times more powerful than humanity, as if it were a microwave or something."

> Meanwhile programming languages should be optimised for reading first.

Interesting, because I totally disagree with this. My preference is for programs designed for safety and amenability to static analysis first. Maybe there's a reason I'm not a Python dev anymore=)

> My early OOP/C++ books are finally more intuitive than something.

Ouch! But seriously, this page is just a someone's jotted out notes. Haskell Programming from First Principles and What I Wish I Knew When Learning Haskell (http://dev.stephendiehl.com/hask/) are the actual pinnacle of Haskell explanations. They have plenty of great examples.

I posted that because I think it's the best you're going to get.

Monads can be two things: (1) a concept in category theory, (2) a rough implementation of that concept in a programming language.

If you want to learn about monads from the category theory perspective, great! This is really hard though, I wouldn't recommend it for most people (and haven't really even succeeded myself).

If you want to learn about a specific programming language's implementation of monads, you will naturally have to know how that language works. This road is far easier than category theory, but still requires knowing (for Haskell) what a typeclass is, what a higher-kinded type is, etc.

It sounds like you want an explanation without prereqs from either category theory or Haskell. If you google for monad tutorials you will find dozens of quick explanations, but I personally don't think this is a good way to actually understand them.

Replying again since I can't edit my comment: Idris, Elm and PureScript.

In addition to the others mentioned, PostgREST: https://github.com/begriffs/postgrest

Sure thing. And thanks, that made me smile.

> it's a float; calling it a fraction is kinda-of-a-lie

This happens not to be correct. By specification JSON numbers are just a series of characters, arranged in a certain way: https://tools.ietf.org/html/rfc7159#section-6

In practice though many JSON parsers will parse non-integer numbers to floats.

> 2. Refuse to handle floats at all, at which point people can pass [ <mantissa>, <exponent> ] for reals or [ <numerator>, <denominator> ] for rationals.

This is a really interesting idea. If you're writing something that's super important like medical software it would probably be worth considering. However, my goals are just to make minimal changes that improve JSON some while still keeping it fairly readable, so I think that means I should stick with allowing `123.456` or whatever. I'd like to try to keep an open mind on this though.

I love that we both started our comments with "jq is great". I hadn't seen yours either=)

Why no top level lists?

Great point about new languages meaning language-aware sorting systems will definitely have breaking changes.

By the way, I love that Bencode is bijective. That's a really nice property for a serialization format, and even though I don't mention it on the README it's one of the goals of Son.

Son's a niche tool to allow talking to JSON services in a more consistent way. It's not meant as an competitor to any other data format.

EDIT: s/alternative/competitor

Dang, `protobuf` doesn't support proto2? I'm kind of a Haskell die-hard, this is a big hole in our ecosystem=(

> I ended up allowing both "1" and "1.0" so I could distinguish integer and floating point literals

Definitely the toughest call when making a JSON subset like this.

This is a great name. I'll probably stick with Son because it's already released, but honestly this would have been better.

There's an issue for min and max number values here: https://github.com/seagreen/Son/issues/3

Son seems like a natural place to put restrictions on them, but I'm not sure if there's way to do it that (A) still makes for a clean spec and (B) still allows everything floats can encode to to be used.

The plan is to go codepoint by codepoint in ascending order:

`{"Z":3,"a":0,"\u0073\u0323\u0307":1,"\u1E69":2}`

See this issue for the discussion: https://github.com/seagreen/Son/issues/1

My current understanding is that RFC 7159 doesn't require Unicode normalization to be performed, if it does we're in trouble: https://tools.ietf.org/html/rfc7159

> not be accepted by a conforming SON parser (that did unicode normalization on incoming keys)

I don't think RFC 7159 actually mentions Unicode normalization at all. If it was in there I think it would be mentioned in the section on string comparisons, but that just talks about going unescaped codepoint by unescaped codepoint: https://tools.ietf.org/html/rfc7159#section-8.3

EDIT: Does Unicode normalization change over time? If so we definitely have to leave it out and just go codepoint by codepoint, because we don't want the validity of a Son document to change.

This is the second time Bencode's been mentioned in the context of Son. I didn't know about it before, it definitely looks interesting! However if you're sending data to a service that only accepts JSON then it's obviously not an option.

You might be interested in JSON5 (http://json5.org/) which goes the opposite direction of Son and makes JSON more human-writeable. It's the best, cleanest "JSON+" I've found so far.