On Sun, Mar 18, 2018 at 2:18 PM, Anders Rundgren <
[email protected]> wrote:
> On 2018-03-18 19:04, Mike Samuel wrote:
>
>> I think you misunderstood the criticism. JSON does not have numeric
>> precision limits.
>>
>
> I think I understood that, yes.
>
> There are plenty of systems that use JSON that never
>> involve JavaScript and which pack int64s.
>>
>
> Sure, but if these systems use the "Number" type they belong to a
> proprietary world where disregarding recommendations and best practices is
> OK.
>
No. They are simply not following a SHOULD recommendation.
I think you have a variance mismatch in your argument.
> BTW, this an ECMAScript mailing list, why push non-JS complient ideas here?
>
Let's review.
You asserted "This discussion (at least from my point of view), is about
creating stuff that fits into standards."
I agreed and pointed out that not tying the definition to JavaScript's
current value limitations would allow it to fit into
standards that do not assume those limitations.
You leveled this criticism: "My guess is that it would be rejected due to
[quite valid] interoperability concerns."
Implicit in that is when one standard specifies that an input MUST have a
property that conflicts with
an output that a conforming implementation MAY or SHOULD produce then you
have an interoperability concern.
But, you are trying to argue that your proposal is more interoperable
because it works for fewer inputs in fewer contexts
and, if it were ported to other languages, would reject JSON that is
parseable without loss of precision in those languages.
How you can say with a straight face that being non-runtime-agnostic makes
a proposal more interoperable is beyond me.
Here's where variance comes in.
MUST on *output* makes a standard more interoperable.
MAY on *input* makes a standard more interoperable.
SHOULD and SHOULD NOT do not justify denying service.
They are guidelines that should be followed absent a compelling reason --
specific rules trumps the general.
Your proposal is less interoperable because you are quoting a SHOULD,
interpreting it as MUST and saying inputs MUST fit into an IEEE 754 double
without loss of precision.
This makes it strictly less interoperable than a proposal that does not
have that constraint.
EmcaScript SHOULD encourage interoperability since it is often a glue
language.
At the risk of getting meta-,
TC39 SHOULD prefer library functions that provide service for arbitrary
inputs in their range.
TC39 SHOULD prefer library functions that MUST NOT, by virtue of their
semantics,
lose precision silently.
Your proposal fails to be more interoperable inasmuch as it reproduces
JSON.stringify(JSON.parse('1e1000')) === 'null'
There is simply no need to convert a JSON string to JavaScript values in
order to hash it.
There is simply no need to specify this in terms of JavaScript values when
a runtime
agnostic implementation that takes a string and produces a string provides
the same value.
This is all getting very tedious though.
I and others have been trying to move towards consensus on what a hashable
form of
JSON should look like.
We've identified key areas including
* property ordering,
* number canonicalization,
* string normalization,
* whether the input should be a JS value or a string of JSON,
* and others
but, as in this case, you seem to be arguing both sides of a position to
support your
proposal when you could just say "yes, the proposal could be adjusted along
this
dimension and still provide what's required."
If you plan on putting a proposal before TC39 are you willing to move on
any of these.
or are you asking for a YES/NO vote on a proposal that is largely the same
as what
you've presented?
If the former, then acknowledge that there is a range of options and
collect feedback
instead of sticking to "the presently drafted one is good enough."
If the latter, then I vote NO because I think the proposal in its current
form is a poor
solution to the problem.
That's not to say that you've done bad work.
Most non-incremental stage 0 proposals are poor, and the process is
designed to
integrate the ideas of people in different specialties to turn poor
solutions to interesting
problems into robust solutions to a wider range of problems than originally
envisioned.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
