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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
