load/as {{
"name": "debug_002_RRDB_ESRGAN_x4_DIV2K"
, "use_tb_logger": true
}} 'JSON
Though I have not read and understood all discussion here(Sorry, not have enough time and knowledge for me), I just want to comment
VS Code treats JSON and JSON with Comments as different languages.
https://drive.google.com/file/d/1rH2lXn1Nms_BDHamyNFMOBin7hgf-ufK/view?usp=sharing
Maybe this is one practical choice example that JSON and JSON with Comments are different.
If Red distinguishes them in the same way, JSON codec(if it is not JSON with Comments codec) does not allow comments is understandable.
getHandleComments
boolean getHandleComments()
Whether to parse or ignore comments - either reading or writing
setHandleComments
IParser setHandleComments(boolean value)
/parsefunction and/or local storage of available parsers in a block. Imagine if some standard develops, and you might welcome versioning, it could be codec/parsers: [1.0 [.....] 1.2 [....]]. Any such storage is dynamically extendable, sortable, searchable, as it is a block or a map.
>> load-json {^{^/ "name": "debug_002_RRDB_ESRGAN_x4_DIV2K"^}}
== #(
name: "debug_002_RRDB_ESRGAN_x4_DIV2K"
)
>> load-json {^{^/ "name": "debug_002_RRDB_ESRGAN_x4_DIV2K" // comment ^/ ^}}
*** User Error: {Invalid json string. Near: ^{^^^{^^/ "name": "debug_002_RRDB_ESRGAN_x4_DI^}}
*** Where: ???My thoughts are that @Oldes problem is perhaps not lack of comments support, but poor Red error message? A problem I also stumbled upon many times. Useful message would be Invalid json string. Near: ^{// comment^}, which would point exactly where the problem is.
Red is expressive enough that (provided you know where exactly your problem is) it's faster to write your own parse rule to clean comments than looking for a suitable npm library in JavaScript world.
@loziniak in current codec implementation (which is not even 1.0, mind you), error reporting has coarse granularity, i.e. it marks location before malformed JSON value (object in this case), and reports it only after parsing have failed.
As for "poor Red messages" see red/red#3282 thread. Informative error reporting in dynamic and homoiconic language (such as Red) is not a trivial problem to solve.
and from Pharo: https://twitter.com/Richo1066/status/1131788453451096068
@9214
I appreciate that error reporting is not trivial, but what we have at the moment is not fit for purpose. It may be more-or-less adequate when debugging the latest dozen lines of code writte while developing (9/10 times the problem is in those lines). But it seems to fundamentally put a limit on the size of Red systems - and/or the ability to easily integrate two separate code bases.
User example - a couple of weeks ago, I experimentally tried to convert a Rebol/Core system (60 scripts, 25,000 lines of code) to Red. I did not expect it to be easy or fun. But I was not expecting to be so misled by errors messages.
Take this one - it took a couple of hours of my life to resolve:
type: 'script id: 'invalid-type arg1: word! near: none where: 'set-pathThere is not a single instance of SET-PATH in the 60 scripts / 25,000 lines of code. So basically, not a single clue in the message where to start looking.
(If you are interested, the bug fix was to make the 'word in a FOREACH local to its function). I got a log of around 20 other errors which might as well have just said "Shrug. Magic bad".
So attacking the non-trivial problem with some priority could well be a unique selling point for Red.
negative-zero and the GTK branch last week, but this week there is activity in refactor-lexer and it does not show up. The links are like https://github.com/red/red/tree/refactor-lexer and similar for all branches.