[Xml-compile] $_[0] + 0.0 for sloppy floats

Patrick Powell papowell at astart.com
Tue Dec 16 15:34:27 GMT 2014


Floats are evil.  This discussion brings back horrible memories of 
1960's and dealing with multiple hardware architectures and floating 
point formats.  IEEE 754 cleared a lot of this up but as we can see 
there are still *())(*& issues with textual representation.

Ummm... and look at JSON and 'true' and 'false'.

Patrick ("True?  You can't handle the 'true'") Powell

On 12/16/14 05:04, Mark Overmeer wrote:
> * hmepas (hmepas at gmail.com) [141216 12:30]:
>> Talking about JSON, I am not seeing any other options actually, than
>> looking into SV. It's the only way to check type of the scalar, beside
>> having scalar stored into object. So the options are:
>> * having objects (slow down and overcomplicate things);
>> * having everything stringified in json;
>> * look into SV.
> When you look at the SV, my choice would be to take the float representation
> over the string representation: a float is more special.
>
>> Bonus option: use language with strict types.
> YAML and JSON are typical examples of "let's make it simpler" (silenty
> to be extended with "to shoot in your own foot")  That's one of the
> few justifications of XML: it is as complex as you can think ;-)
>
> I think strict interfaces are the most important base for stable
> programming.  Why do people pick a sloppy interface format (JSON), and
> then a strict programming language (Java)?  Better use string interaces
> (XML) and sloppy languages (Perl)  ;-b
>
>> About making every key in json a string
>> { "MapPoint" : { x : "10.2", y : "45.9" }  }
>> this json code will break deserialization for strict typing languages like,
>> java. If x and y is floats in java.
> I don't know.  Probably depends on the JSON library used.  As parser, I
> would implemented some smartness if untyped information gets read for
> my strongly typed language.
>
>> Do I miss something?
> If you feel that JSON should produce typed info, you may ask the authors
> of those implementations to solve that.


-- 
Patrick Powell                 Astart Technologies
papowell at astart.com            1530 Jamacha Rd, Suite X
Network and System             San Diego, CA 92019
   Consulting                   858-874-6543 FAX 858-751-2435
Web: www.astart.com




More information about the Xml-compile mailing list