Monte Goulding's day off? ; -) the outcome.

[Mark Waddingham]

On 2016-06-30 17:00, Lagi Pittas wrote:
> Now here is the reason I got on my high horse. The code to build the 
> JSON
> string and save it to a file is miniscule. The bit to fix the JSON is
> longer and will need a  a unique version for a different formatted JSON
> file unless I write a parser/tokeniser  that will find real numbers 
> with a
> precision greater than 2 (in this case).

Well, high horses are fine - but just remember that the higher you are, 
the more likely to hurt yourself if you fall off ;)

This case actually illustrates quite well the difficulty with trying to 
'bridge' the (abstraction) gap between a very high level language like 
LiveCode Script and a lower level language like C. It isn't an easy 
thing to do, nor is it necessarily always 'obvious' what the approach 
should be.

The mergJSON external does the best it can in terms of mapping the way 
jansson (the C library it uses) to the way the old-style external 
interface allows you to present values. As it turns out, what has been 
identified is that (for LiveCode Script, at least) it would be far 
better if the string value of the tokens parsed as values were used and 
not their conversion to their actual type - but jansson does not work 
like that because it is designed to be used from C and friends (and is 
so very successfully in a large number of projects).

There have been two very useful outcomes from this conversation, 
however:

   1) Any JSON parser usable from LiveCode Script (right now) should just 
return all values as strings - it should check they are well-formed as 
per the JSON spec, but not actually attempt to convert or process them 
as the engine is more than capable of doing that for you. (Except for 
quoted values in JSON - they need to be 'unescaped').

   2) Ideally there would (internally) be a form of 'stringy-number' 
which work consistently with 'the numberFormat'. If this were the case, 
then you get the best of both worlds - the actual type of any value 
specified in the JSON input file would be detectable by using the 'is 
strictly' operators; but you'd still retain the specific representative 
string for a number that was present in the input if you just wanted to 
treat things as strings. (i.e. You gain 'faithfulness' of 
representation, without taking away the ability to know what the author 
of the JSON file really meant).

Indeed (2) goes further - since 7+ we've been struggling with the 
'correct' approach to numeric literals in script - their handling has 
been changed a number of times to try and ensure things work 
consistently and well; up until now my general thoughts were that they 
were handled the best way they could be with the numeric representation 
internally (for numbers) being binary floating point and the only thing 
that would make them better would be to switch to decimal floating 
point. However, the latter comes with a hefty performance cost (outside, 
perhaps, of certain IBM mainframes whose processors can do decimal 
floating point in hardware). Allowing numeric literals to also carry 
their 'representative string', and making sure they are used 
appropriately with 'the numberFormat' would clean this part of the 
engine up considerably.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps