Hi Marco,

Thanks for the great news:-)

An additional question on the parser before we move on with some kind of implementation! We will use the library for end-user scripting in a desktop-centric app, not for arbitrary web data transfer on http. Basically as a way to offer extensive user-defined "parameter-setting" on an arbitrary large set of pre-defined display settings.

oJSON = json_read('{"PrintDate":"2017-03-10", "XLabels":["Caracas","Maracaibo","Valencia"], "BaseColor":[128,128,128], "CopyCount":2, "VectorOutput":true}')

I was able to replace the EMPTY class with COLLECTION. Which allows for easy collection-style introspection of the string, numeric or array input (as embedded collections). This will certainly offer expressive hacking by our users and will happily replace possibly a large host of dialog box options:-)

The output is set into case-insensitive VFP collections that will be discovered as "tuning" information for programmatic control for highly complex visual output via sub-classed collections. Getting the content is quite easy:
? "Settings count:"+TRANSFORM(oJson.count),"Print Date:"+oJson("printdate"),oJson.Item(2).item(1)
>> Settings count:4 Print Date:2017-03-10 Caracas

JSON Key strings are of course js standard strings and delimited with double-quotation marks such as {"firstName": "John", "lastName": "Smith"}.

Do you have an idea whether I could easily hack your code base - parsing is a bit over my head - in order to offer plain keys instead of double-quoted entries ? {firstName: "John", lastName: "Smith"} instead of {"firstName": "John", "lastName": "Smith"}. The keys that our users will be defined programmatic parameters (alphanumeric symbols with no embedded spaces), not arbitrary text data.

{PrintDate:"2017-03-10", XLabels:["Caracas","Maracaibo","Valencia"], BaseColor:[128,128,128], CopyCount:2, VectorOutput:true} would be an easier read and write than series of double-quoted entries!

I of course understand that such a hack - sure a diversion from the JSON grammar! - may not be achievable easily or may break the carefully crafted code of your nfjsonread prg. It certainly runs nice as it is currently. But if that added hack were possible without too much collateral damage, I'd be glad to hear :-)

Of course there may be alternative solutions that I am not aware of. I got it you have a YAML parser in the cooking phase. Great! YAML, JSON, CSV, INI, there are many ways to set up text files in a way which is more pleasant to type than, say, xml... Anyway possibly, we should think twice before tweaking the JSON syntax. Setting parameters via "fully quoted strings with embedded blanks" has its set of advantages: it calls for localizing and clearer texts may reduce the need for documentation as well.

Daniel