Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38632 > unrolled thread

JSON, definitions, standards - things I do not understand

Back to article view | Back to comp.lang.javascript

Contents

  JSON, definitions, standards - things I do not understand retired developer <retired.developer@protonmail.com> - 2020-08-04 03:33 +0200
    Re: JSON, definitions, standards - things I do not understand Julio Di Egidio <julio@diegidio.name> - 2020-08-04 02:07 -0700
      Re: JSON, definitions, standards - things I do not understand retired developer <retired.developer@protonmail.com> - 2020-08-04 12:54 +0200
        Re: JSON, definitions, standards - things I do not understand Julio Di Egidio <julio@diegidio.name> - 2020-08-04 06:00 -0700
        Re: JSON, definitions, standards - things I do not understand Julio Di Egidio <julio@diegidio.name> - 2020-08-04 06:25 -0700
        Re: JSON, definitions, standards - things I do not understand Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-08-05 10:15 +0200
          Re: JSON, definitions, standards - things I do not understand Julio Di Egidio <julio@diegidio.name> - 2020-08-05 02:30 -0700

#38632 — JSON, definitions, standards - things I do not understand

Hello,

I hope this is the right place for my questions, if not, please redirect 
me to the proper group.
Thanks.

Beside JavaScript, I use another programing language too where JSON is 
supported.

During a data import (data in JSON format) I found a typo in my imported 
data, but the import was without any error message.
What the heck is that, I thought, and started some digging...

Here are the results, and I'm stumped.

The html file (see below) was opened with Google Chrome.
The output (see below too) looks a little bit buggy, but I think, the 
staff at Google will know, what they do, so there must be some kind of 
explanation for this output.

Is there someone here who can enlighten me?

Thank you,
Julius

--- the html-file --------------------------
<!DOCTYPE html>
<html>
<script>
function jsonThings() {
   var arr1, arr2, str, tmp;
   var i, j;

   str = "[ 11,, null]" ; // the ,, was a typo
   try { arr1 = JSON.parse(str); add(str,"Must be a coincidence..."); }
   catch(e) { add(str,e.message); }

   arr2 = [11,,null];
   add(JSON.stringify(arr2),"empty field (,,) is parsed!");

   size = arr2.length;
   add("array-size: "+size, "nonexistent (undefined) items are counted");

   tmp = "";
   j = 0;
   for (i=0; i<size; i++) { tmp += i + " " + typeof(arr2[i]) + "<br>"; j++;}
   add(tmp, "FOR loop is executed "+j+" times");

   tmp = "";
   j=0;
   for (i in arr2) { tmp += i + " " + typeof(arr2[i]) + "<br>"; j++; }
   add(tmp,"The loop is executed "+j+" times!");

   tmp = arr2[0];
   for (i=1; i<size; i++) { tmp += ","+arr2[i]; }
   add(JSON.stringify(arr2),"["+tmp+"] Stringify vs. content. Which one 
is correct?");

}

function add(str,msg) {
   var obj = document.getElementById("msg");
   var itm = document.createElement("P");
   itm.innerHTML = str + " --> " + msg;
   obj.appendChild(itm)
}
</script>

<body onload="jsonThings();">
<div id="msg" />
</body>
</html>
--- end-of-html-file --------------------------------------

--- the-output --------------------------
[ 11,, null] --> Unexpected token , in JSON at position 5

[11,null,null] --> empty field (,,) is parsed!

array-size: 3 --> nonexistent (undefined) items are counted

0 number
1 undefined
2 object
--> FOR loop is executed 3 times

0 number
2 object
--> The loop is executed 2 times!

[11,null,null] --> [11,undefined,null] Stringify vs. content. Which one 
is correct?
--- end-of-output -------------------------------------


-- 
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

[toc] | [next] | [standalone]

#38642

On Tuesday, 4 August 2020 03:33:51 UTC+2, retired developer  wrote:

> During a data import (data in JSON format) I found a typo in my imported 
> data, but the import was without any error message.
> What the heck is that, I thought, and started some digging...

JSON is not JavaScript, strictly speaking it is not even a subset of
JS: in particular, arrays in JS are sparse, but there is no such thing
in JSON.  Which overall means you have to be careful when serialising/
deserialising (i.e. in JS with JSON.stringify/JSON.parse).

This is a quick explanation of the extra-commas in array literals
(in JS, not JSON!), although it is not totally correct: those "empty"
elements are not set to undefined, they are altogether absent (from
the sparse array):
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_Types#Extra_commas_in_array_literals>

In JS, (in general) arrays are sparse and are a specialisation of
objects, e.g. an array such as [1,,3] is akin to an object
{ "0": 1, "2": 3 } (I say "akin", not equal, since of course arrays
have their own extra methods).

Now, while the length of a sparse array is still 1 more than the
index of the last element, when you do a for-in loop, undefined
elements get skipped... and so on.  It's just how it is.  JSON is
different and simpler: indeed, it is a known issue with JSON that
it does not match 1-1 with JS in particular for arrays (there is
no direct way to pass sparse arrays in JSON, one has to encode/
decode the array contents with some custom scheme)...

I hope that gives you an idea.

Julio

[toc] | [prev] | [next] | [standalone]

#38646

On 04.08.20 11:07, Julio Di Egidio wrote:

Hello Julio,

thank you for the explanations.


> JSON is not JavaScript, strictly speaking it is not even a subset of
> JS: in particular, arrays in JS are sparse, but there is no such thing
> in JSON.  Which overall means you have to be careful when serialising/
> deserialising (i.e. in JS with JSON.stringify/JSON.parse).

OK, JSON is not JavaScript. Clear. One is a "data structure" and the 
other is a (programming) language. But they are related to each other, 
we use JSON structures in JavaScript to solve problems. So at the end of 
the day we work with JSON objects in our JavaScripty code.

Can you explain, why is

var myarray = [11,22,,44,55];

a correct statement but

var mydata = "[11,22,,44,55]";
var myarray = JSON.parse(mydata);

gives an error - Can't parse [11,22,,44,55]?

The former is the same as the latter!
The difference is the parse time only. The first is parsed at compile 
time the second is parsed at runtime.


> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_Types#Extra_commas_in_array_literals>

thanks for the link.


> In JS, (in general) arrays are sparse and are a specialisation of
> objects, e.g. an array such as [1,,3] is akin to an object
> { "0": 1, "2": 3 } (I say "akin", not equal, since of course arrays
> have their own extra methods).

I have no problem with sparse arrays. I know and work with them since 1978.

> Now, while the length of a sparse array is still 1 more than the
> index of the last element, when you do a for-in loop, undefined
> elements get skipped... and so on.  It's just how it is.  JSON is
> different and simpler: indeed, it is a known issue with JSON that
> it does not match 1-1 with JS in particular for arrays (there is

JavaScript handles sparse arrays in a way I can't follow.

I don't understand, why the length property
array.length = <indexOfTheLastElement + 1>
does counts missing elements too. In this case JavaScript thinks "in the 
old fashioned way", an array has always all elements, from the first 
until the last.

I would have done it that way:
array.count  = <countOfExistingElemens>
array.first  = <indexOfFirstExistingElement>
array.last   = <indexOfLastExistingElement>
array.length = <indexOfLastElement + 1> // to be compatible with old SW

array.next(i)  a function, to give the next existing element after <i>
                start value for i: null
                end  value  for i: null

Example:
var arr1 = [11,,33];
var arr2 = [, 22,,44];

arr1.count --> 2
arr1.first --> 0
arr1.last  --> 2
arr1.length -> 3
arr1.next(null) --> 0
arr1.next(0)    --> 2
arr1.next(2)    --> null

arr2.count --> 2
arr2.first --> 1
arr2.last  --> 3
arr2.length -> 4
arr2.next(null) --> 1
arr2.next(0)    --> 1
arr2.next(1)    --> 3
arr2.next(3)    --> null

> I hope that gives you an idea.
Oh yes, I got it...

Regards,
Julius

-- 
An old Windows has old security holes.
A new Windows has new security holes.
Another OS has other security holes.
For safety you must care yourself.

[toc] | [prev] | [next] | [standalone]

#38647

On Tuesday, 4 August 2020 12:54:41 UTC+2, retired developer  wrote:
> On 04.08.20 11:07, Julio Di Egidio wrote:

> > JSON is not JavaScript, strictly speaking it is not even a subset of
> > JS: in particular, arrays in JS are sparse, but there is no such thing
> > in JSON.  Which overall means you have to be careful when serialising/
> > deserialising (i.e. in JS with JSON.stringify/JSON.parse).
> 
> OK, JSON is not JavaScript. Clear. One is a "data structure" and the 
> other is a (programming) language. But they are related to each other, 
> we use JSON structures in JavaScript to solve problems. So at the end of 
> the day we work with JSON objects in our JavaScripty code.

No, JSON is a data format, not even a data structure: rather you can
encode, aka serialise, (programming) structures to text based on that
or other (textual: same goes for other formats) data format.

> Can you explain, why is
> 
> var myarray = [11,22,,44,55];
> 
> a correct statement but

The JS parser succeeds because that is valid JS syntax.

> var mydata = "[11,22,,44,55]";
> var myarray = JSON.parse(mydata);
> 
> gives an error - Can't parse [11,22,,44,55]?

The JSON parser fails because that is *not* valid JSON syntax.

> The former is the same as the latter!
> The difference is the parse time only. The first is parsed at compile 
> time the second is parsed at runtime.

Nope, see above.  Rather, the overlap of JSON to a subset of JS is a
major source of confusion, at least in the corner cases, unless one
does have those distinctions clear.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#38648

On Tuesday, 4 August 2020 12:54:41 UTC+2, retired developer  wrote:
> On 04.08.20 11:07, Julio Di Egidio wrote:

> > In JS, (in general) arrays are sparse and are a specialisation of
> > objects, e.g. an array such as [1,,3] is akin to an object
> > { "0": 1, "2": 3 } (I say "akin", not equal, since of course arrays
> > have their own extra methods).
> 
> I have no problem with sparse arrays. I know and work with them since 1978.

Out of curiosity, in what language(s)?

> > Now, while the length of a sparse array is still 1 more than the
> > index of the last element, when you do a for-in loop, undefined
> > elements get skipped... and so on.  It's just how it is.  JSON is
> > different and simpler: indeed, it is a known issue with JSON that
> > it does not match 1-1 with JS in particular for arrays (there is
> 
> JavaScript handles sparse arrays in a way I can't follow.
> 
> I don't understand, why the length property
> array.length = <indexOfTheLastElement + 1>
> does counts missing elements too. In this case JavaScript thinks "in the 
> old fashioned way", an array has always all elements, from the first 
> until the last.
> 
> I would have done it that way:
> array.count  = <countOfExistingElemens>
> [...]
> array.length = <indexOfLastElement + 1> // to be compatible with old SW

Length is arguably useful in itself (you cannot do an indexed loop over
the Count, nor when you do a Join you skip missing elements, and so on),
plus Length is totally natural to have (it comes at no additional cost).

OTOH, a Count of existing elements (which is not even a count of elements
that are not equal to undefined: but this is yet another story with JS!)
is hardly useful unless to track the size in memory of the array (which is
too low-level in JS anyway), and it does come with a serious additional
cost if built-in, so in ECMAScript they haven't done it: the user can
still implement it if he needs, as well as the prev/next methods and
whatnot, by suitably wrapping the array.  Problem solved: efficiently.

Julio

[toc] | [prev] | [next] | [standalone]

#38665

retired developer wrote:
^^^^^^^^^^^^^^^^^
Your real name belongs there.

> On 04.08.20 11:07, Julio Di Egidio wrote:
> 
> Hello Julio,

This is a public Usenet newsgroup.  If you want to communicate with only one 
person, write them an e-mail.
 
>> JSON is not JavaScript, strictly speaking it is not even a subset of
>> JS: in particular, arrays in JS are sparse, but there is no such thing
>> in JSON.  Which overall means you have to be careful when serialising/
>> deserialising (i.e. in JS with JSON.stringify/JSON.parse).
> 
> OK, JSON is not JavaScript. Clear. One is a "data structure" and the
> other is a (programming) language. But they are related to each other,
> we use JSON structures in JavaScript to solve problems. So at the end of
> the day we work with JSON objects in our JavaScripty code.

No.  JSON is a *small* *subset* of valid ECMAScript code.

  {'foo': /bar/}

is valid ECMAScript code.  It is NOT valid JSON: in JSON, string literals 
have to be delimited with <">, not <'>, and there are no RegExp literals.
 
> Can you explain, why is
> 
> var myarray = [11,22,,44,55];
> 
> a correct statement but
> 
> var mydata = "[11,22,,44,55]";
> var myarray = JSON.parse(mydata);
> 
> gives an error - Can't parse [11,22,,44,55]?

Because it satisfies the *ECMAScript* grammar, but not the *JSON* grammar.

<https://json.org/>

The only way to have that parsed into a value equivalent to the one assiged 
above is using eval().
 
> The former is the same as the latter!

No, it isn’t.

> The difference is the parse time only.

No, the first is a piece of ECMAScript code.  The second is supposed to be 
parsed as JSON.

> The first is parsed at compile time the second is parsed at runtime.

Yes, but that is not the only difference.

>> In JS, (in general) arrays are sparse

No.  You can have sparse arrays, though.

>> Now, while the length of a sparse array is still 1 more than the
>> index of the last element, when you do a for-in loop, undefined
>> elements get skipped... and so on.  It's just how it is.  JSON is
>> different and simpler: indeed, it is a known issue with JSON that
>> it does not match 1-1 with JS in particular for arrays (there is
> 
> JavaScript handles sparse arrays in a way I can't follow.
> 
> I don't understand, why the length property
> array.length = <indexOfTheLastElement + 1>
> does counts missing elements too.

Because it does not give the number of elements, but the value of the 
greatest used index + 1.

> In this case JavaScript thinks "in the
> old fashioned way", an array has always all elements, from the first
> until the last.

No, *you* are thinking the old-fashioned way.
 
> I would have done it that way:

Nobody cares about your inefficient fantasies.  But you are free to subclass 
Array to implement additional features if you find them necessary or useful.

> array.count  = <countOfExistingElemens>
> array.first  = <indexOfFirstExistingElement>
> array.last   = <indexOfLastExistingElement>

  class RetiredDeveloperArray extends Array
  {
    constructor (...args)
    {
      if (Array.isArray(args[0]))
      {
        super(...args[0]);
      }
      else
      {
        super(...args);
      }
    }

    get count () { return Array.from(this.keys()).length; }
    get first () { return Array.from(this.keys())[0]; }
    get last () {
      let keys = Array.from(this.keys());
      return keys[keys.length - 1];
    }
  }

Then use “new RetiredDeveloperArray([11, 22,, 44, 55])” instead of
”[11, 22,, 44, 55]”.

> array.next(i)  a function, to give the next existing element after <i>
>                 start value for i: null
>                 end  value  for i: null

That would be a _method_.  “End value”?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#38668

On Wednesday, 5 August 2020 10:15:33 UTC+2, Thomas 'PointedEars' Lahn  wrote:
> retired developer wrote:
> ^^^^^^^^^^^^^^^^^
> Your real name belongs there.
> 
> > Hello Julio,
> 
> This is a public Usenet newsgroup.  If you want to communicate with only
> one person, write them an e-mail.

Addressing people personally, even publicly on Usenet, is perfectly
legitimate.  You are delusional.

> > gives an error - Can't parse [11,22,,44,55]?
> 
> Because it satisfies the *ECMAScript* grammar, but not the *JSON* grammar.
> 
> <https://json.org/>
> 
> The only way to have that parsed into a value equivalent to the one assiged 
> above is using eval().

By the way, whatever it putatively satisfies, *it is not JSON*, that was
the answer!  And eval being *the JS parser*, you are just talking vacuous
nonsense... for one thing.

Rather it is *stupid*, on your part, and utterly *uncollaborative*, as
for actual etiquette, to post an answer from scratch on top of mine and
with not even a hint of continuity or at least engagement.

You are a complete and worse than useless idiot...

*Plonk*

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web