Option to produce source maps (src-dest line mapping)

[Zearin]

So, apparently Groupon has become the steward of the CSON parser. Cool!

Before that happened, I had requested (in bevry/cson#29) the ability for CSON to produce source maps, much as the normal CoffeeScript compilation process provides.

Due to the factoring out of the CSON parser itself, my understanding is that bevry/cson can only implement source maps if this project provides the means. Many modern tools support source mapping, and even tools that bundle multiple *.js files into one (e.g., browserify) support source mapping.

But CSON does not. I have used CSON in several projects, including some where it is of strong importance—not merely “syntactic sugar”, but the difference between maintainable code and a lost cause. I believe source mapping support would make CSON significantly more attractive. (And—who knows?—perhaps a more attractive CSON might bring more devs to this repository out of curiosity. ☻ And that could mean more Pull Requests that save you some work!)

But apart from all that, I think source mapping is “the right thing to do” for cson-parser. What do you think?

[jkrems]

Hi - thanks for the suggestion! Since the output of cson-parser is data (and not any fixed string representation, e.g. JSON), it would be a bit tricky but I'm sure not impossible to support source maps.

Reading through the original issue - did you investigate YAML? It's human readable, has good support across platforms, and has some advanced features. It's more complex but for your use case (describing test cases) that additional complexity might even be useful..?

[Zearin]

Reading through the original issue - did you investigate YAML?

I’m pretty sure this is an unpopular opinion, but I’ve never liked YAML. I used to be pretty immersed in XML, and YAML just seemed like a shorthand for XML, but without any benefits of a “parent language”. Among other things, that means it needs other languages to write parsers for it—rather than simply being a subset of an existing language.

Since XML has fallen out of fashion with the rise of JSON, I found that I enjoyed using CoffeeScript. And CSON has CoffeeScript as its parent language, just as JSON has JavaScript. It just “feels” more “appropriate” to me, and a much more attractive option, than YAML ever was.

Source maps for CSON are the only thing missing. :)

[Zearin]

it would be a bit tricky but I'm sure not impossible to support source maps.

In what way? Could you elaborate?

I’m not a great CoffeeScript coder or anything, but if there’s anything I can do to help, I will. (Also, if it requires anything that is “tedious”, I don’t mind doing that either, as long as someone can give me clear directions what to do.)

[jkrems]

I used to be pretty immersed in XML, and YAML just seemed like a shorthand for XML, but without any benefits of a “parent language”. Among other things, that means it needs other languages to write parsers for it—rather than simply being a subset of an existing language.

This might be side-tracking the current issue - but I'd say ruby is the "parent language" of YAML. And just like XML and JSON it has the advantage that there are parsers for at least the "big" languages. It's definitely far better supported than CoffeeScript and by proxy CSON.

it would be a bit tricky but I'm sure not impossible to support source maps.

In what way? Could you elaborate?

The problem is that we never actually generate JavaScript (or JSON). Source maps imply that there are two string representations of the same AST - which is not the case here. We could definitely generate something like an "object path to location" map. But to actually use it you'd need to generate the JSON "by hand" or somehow generate the mappings in a post-processing step.

Also the fact that the same data stored as JSON can also be stored as CSON or YAML is purely incidental. CSON is not actually defined as an alternative formatting for JSON. There are actually values CSON can represent that JSON can't. E.g. the following CSON file does not have a meaningful JSON representation:

# $ node -p 'require("cson-parser").parse("1 / 0")'
# Infinity
# $ node -p 'JSON.stringify(require("cson-parser").parse("1 / 0"))'
# null
1 / 0

P.S.: Just to clarify the first paragraph - JSON is not a subset of JavaScript if that's what you meant by "parent language".