arnomi

arnomi

I recently added a proposal for Jason to add an option to allow decoding and encoding of NaNs (not a number) and ± infinity. This would allow decoding strings such as

{ "v1": NaN, "v2": Infinity }

So far the discussion was mainly between @OvermindDL1 and myself, and I would like to get more feedback on this.

Here is the gist of it.

Fact: The JSON spec doesn’t support it. Furthermore, it explicitely discourages it.

Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted. (RFC 7159)

Fact: Quite a few parsers out there have the option to deal with NaNs. Many of these even have this option enabled by default (which leads to quite a bit of “JSON” out there which is not spec compliant):

  • Python enables NaNs by default and provides an option to be spec complient

    > import json
    > data =  [float('nan'), float('inf'), float('-inf')]
    > data
    [nan, inf, -inf]
    > json.dumps(data)
    '[NaN, Infinity, -Infinity]'
    
  • GSON (JVM) provides an option to deal with NaNs but is spec compliant by default

  • Julia provides an option to deal with NaNs but is spec compliant by default

  • OCaml Yojson enables NaNs by default and offers a flag to be spec compliant

Fact: Various parsers do not allow for NaNs. This includes

  • JavaScript
  • Go
  • Rust
  • Currently all Elixir JSON libs

Question: What is an appropriate choice for a JSON parser?

  1. Be spec compliant and do not provide options for deviating from that.
  2. Allow for NaN parsing on the basis that JSON in the wild may be not spec compliant and the only way to properly deal with such strings is to write a JSON parser that can deal with these.

Looking forward to feedback.

Showing Posts 1 to 2

alco

alco

What would be the expected behaviour in Elixir when parsing a JSON document with NaNs? BEAM doesn’t support NaN nor infinities, so I would expect to get back an error saying the input can’t bee decoded.

But if we’re talking about an extension to the parser, then it should probably define its own representation for such invalid values, e.g. parse NaNs into :NaN, and user code will have to depend on this particular representation. Moreover, I assume there’s not universal representation for encoding such value in different languages (it’s not part of the spec and there’s no separate spec for handling NaNs and infinities).

These observations lead me to the conclusion that it won’t be sufficient to add an option to a JSON library to enable support for non-conformant values because there may be different representations for such values in the wild.

A proper solution from a JSON library perspective would be to allow the user to hook into the parser and extend it in the desired way. So I see it as an extension mechanism rather than a single configuration option.

xxoo

xxoo

You can use jsex in javascript projects. which is an extended JSON serializer/deserializer. it supports NaN, Infinity and many other data types.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 92995 915
New
caslu
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
GES233
I’m posting this in response to Jose’s recent tweet (Cr. link) : People are sleeping on Elixir for a coding harness: Hot-code swappi...
New
_mfierro
Hello, I wrote Stop My Hand, a Scattergories-like web application using Phoenix/LiveView as my learning project for Elixir (after readin...
New
marciol
It would be helpful to have a list of companies worldwide that hire engineers without prior experience in Elixir. Often, it can be quite ...
New
durvia
Anyone running long-lived stateful processes on BEAM? We’re building an AI agent runtime and would love to compare notes. We’re a small ...
New

Other Trending Topics Top

garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews