!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

422 Members
(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.142 Servers

Load older messages


SenderMessageTime
14 Aug 2025
@emilazy:matrix.orgemily IOW, the nlohmann_json semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float" 14:54:35
@emilazy:matrix.orgemily if we were to implement "we try to find an integer type we can fit a literal into, and otherwise we produce a float" in Nix, we should produce a float for builtins.fromJSON "9223372036854775808" 14:54:52
@emilazy:matrix.orgemily otherwise, if we want "we reject integer-looking literals that don't fit into an integer type, and produce a float only for explicitly float-y values", we should error out on builtins.fromJSON "-9223372036854775809" 14:55:16
@emilazy:matrix.orgemily the current combination of behaviour seems like an unjustifiable accident caused by the impedance mismatch between nlohmann_json's API oriented around C++ numeric types, and Nix's signed-only integers 14:55:45
@emilazy:matrix.orgemilyP.S. I want to cry14:56:12
@weethet:catgirl.cloudWeetHet @raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862 15:29:28
@piegames:flausch.socialpiegames
In reply to @emilazy:matrix.org
IOW, the nlohmann_json semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float"
Thanks, I hate it
15:34:14
@emilazy:matrix.orgemilywell, blame JavaScript :)15:34:30
@emilazy:matrix.orgemily(and JSON for not specifying any goddamn semantics at all at first)15:34:35
@piegames:flausch.socialpiegamesTbh if a library does untyped bullshit like that, I preferably want it out of my sight15:34:47
@emilazy:matrix.orgemilyno, this is just JSON15:34:58
@emilazy:matrix.orgemilyJSON has only one numeric type, because JavaScript does15:35:05
@emilazy:matrix.orgemilyits type is even vaguer than JavaScript's however15:35:09
@emilazy:matrix.orgemilyI don't have a strong opinion on "reject integer-looking things that are out of Nix integer range" vs. "always produce floats for things outside of Nix integer range"; both have their merits. the current state seems unjustifiable though15:35:36
@charles:computer.surgeryCharlesi thought that JSON just didn't define any constraints on numeric types15:36:09
@raitobezarius:matrix.orgraitobezarius
In reply to @weethet:catgirl.cloud
@raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862
In ~ 5 days, yeah
15:35:52
@charles:computer.surgeryCharlesand left that as an implementation detail15:36:25
@emilazy:matrix.orgemilyit depends what you mean by "JSON".15:36:29
@emilazy:matrix.orgemilythe original terrible specification defines syntax and says basically nothing about semantics at all https://www.json.org/json-en.html15:36:45
@emilazy:matrix.orgemily "A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used." 15:36:51
@charles:computer.surgeryCharleslolsob15:36:56
@emilazy:matrix.orgemily

the latest RFC defines a single numeric type and says

This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
available and widely used, good interoperability can be achieved by
implementations that expect no more precision or range than these
provide, in the sense that implementations will approximate JSON
numbers within the expected precision. A JSON number such as 1E400
or 3.141592653589793238462643383279 may indicate potential
interoperability problems, since it suggests that the software that
created it expects receiving software to have greater capabilities
for numeric magnitude and precision than is widely available.

Note that when such software is used, numbers that are integers and
are in the range [-(253)+1, (253)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.

15:37:10
@emilazy:matrix.orgemily *

the latest RFC defines a single numeric type and says

   This specification allows implementations to set limits on the range
   and precision of numbers accepted.  Since software that implements
   IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
   available and widely used, good interoperability can be achieved by
   implementations that expect no more precision or range than these
   provide, in the sense that implementations will approximate JSON
   numbers within the expected precision.  A JSON number such as 1E400
   or 3.141592653589793238462643383279 may indicate potential
   interoperability problems, since it suggests that the software that
   created it expects receiving software to have greater capabilities
   for numeric magnitude and precision than is widely available.

   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.
15:37:16
@emilazy:matrix.orgemilythere is an RFC that subsets it into an interoperable subset that IIRC they say that IETF specifications SHOULD use; I believe it limits the range to the interoperable subset15:37:39
@emilazy:matrix.orgemilybut I'd have to check15:37:42
@emilazy:matrix.orgemily Nix could just always parse numeric literals in JSON into floats, but it would be annoying. (especially since Nixpkgs backs its integer-parsing functions by fromJSON) 15:38:05
@weethet:catgirl.cloudWeetHet
In reply to @raitobezarius:matrix.org
In ~ 5 days, yeah
Thanks
15:38:15
@emilazy:matrix.orgemily

ok, I-JSON says

   Software that implements IEEE 754-2008 binary64 (double precision)
   numbers [IEEE754] is generally available and widely used.
   Implementations that generate I-JSON messages cannot assume that
   receiving implementations can process numeric values with greater
   magnitude or precision than provided by those numbers.  I-JSON
   messages SHOULD NOT include numbers that express greater magnitude or
   precision than an IEEE 754 double precision number provides, for
   example, 1E400 or 3.141592653589793238462643383279.

   An I-JSON sender cannot expect a receiver to treat an integer whose
   absolute value is greater than 9007199254740991 (i.e., that is
   outside the range [-(2**53)+1, (2**53)-1]) as an exact value.

   For applications that require the exact interchange of numbers with
   greater magnitude or precision, it is RECOMMENDED to encode them in
   JSON string values.  This requires that the receiving program
   understand the intended semantic of the value.  An example would be
   64-bit integers, even though modern hardware can deal with them,
   because of the limited scope of JavaScript numbers.
15:38:53
@emilazy:matrix.orgemilyok, Nixpkgs does in fact detect the float case for integer conversions15:39:36
@emilazy:matrix.orgemilyso "fits into Nix integer → Nix integer, otherwise → float" would be desirable for Nixpkgs and consistent with other JSON implementations15:39:58

Show newer messages


Back to Room ListRoom Version: 10