3 ms·

My JSON parser ( github.com/nanoscopic/ujsonin ) has these things: 0. Looks essentially the same as JSON 1. Core data types, and customizable data types can b

My JSON parser ( github.com/nanoscopic/ujsonin ) has these things: 0. Looks essentially the same as JSON 1. Core data types, and customizable data types can be added easily. 2. Arrays, Objects, and arbitrary nesting. 3. Comments ( both /* */ and // format ) 4. Multiline strings ( by default; carriage returns are no problem within strings ) 5. It is JSON with relaxed restrictions and slight addition for actual named types. 6. I've written C, Perl, and Golang implementations so far.

jasfi 5y ago
I like the idea of what you're doing. May I suggest a Nim port? Nim outputs C anyway, but is safe, so you'd worry less about bugs.
- nanoscopic 5y ago
  Thank you. Glancing through the Nim documentation it doesn't appear to support goto. Searching online reveals one can hack something into the underlying instruction set, but it looks very unclean. To port my parser I would need to alter the core of the processor a bunch to make it effectively be a large switch statement inside of a loop to build the state machine. Right now all three implementation are essentially following the same logic with just the language syntax altered between them to make maintenance of all implementations simultaneously easier. I have spent some time generating ragel grammars for this sort of thing, and ragel can output a number of different languages itself. The code generated by ragel, is, though, quite messy itself and can have random problems that require workarounds, which is why I haven't decided fully upon going down the ragel path. May I ask what the point is of having a Nim port? You've listed safety; which can be better addressed by building a state machine generator and a state machine DSL. Also, the code is quite small, so I don't think "safety" is the primary concern for the codebase. Nim compiles to C, C++, and Javascript. I can already effectively run the C parser in JS by compiling to WASM ( and I've done so with my XML parser ) C++ code can call the C code without issue. A wrapper to auto-call object deletion in C++ would be trivial to write. Rewriting in Nim would not, so far as I can see, offer any benefits to me that are worth the effort.

jasfi 5y ago

I like the idea of what you're doing. May I suggest a Nim port? Nim outputs C anyway, but is safe, so you'd worry less about bugs.

nanoscopic 5y ago
Thank you. Glancing through the Nim documentation it doesn't appear to support goto. Searching online reveals one can hack something into the underlying instruction set, but it looks very unclean. To port my parser I would need to alter the core of the processor a bunch to make it effectively be a large switch statement inside of a loop to build the state machine. Right now all three implementation are essentially following the same logic with just the language syntax altered between them to make maintenance of all implementations simultaneously easier. I have spent some time generating ragel grammars for this sort of thing, and ragel can output a number of different languages itself. The code generated by ragel, is, though, quite messy itself and can have random problems that require workarounds, which is why I haven't decided fully upon going down the ragel path. May I ask what the point is of having a Nim port? You've listed safety; which can be better addressed by building a state machine generator and a state machine DSL. Also, the code is quite small, so I don't think "safety" is the primary concern for the codebase. Nim compiles to C, C++, and Javascript. I can already effectively run the C parser in JS by compiling to WASM ( and I've done so with my XML parser ) C++ code can call the C code without issue. A wrapper to auto-call object deletion in C++ would be trivial to write. Rewriting in Nim would not, so far as I can see, offer any benefits to me that are worth the effort.