1. What problem are you solving with this? This really seems like a solution in search of a problem.<p>2. There's no emitter, just a parser. This suggests to me that there's no such thing as a canonical LCON transformation for a given input. This is bad.
I love yaml because I can see it, and it (usually) makes sense. Same thing with Markdown. They both visually represent the data/content in a manner that my brain gets.<p>This seems less obvious (or slower to digest) but I've stared at yaml and markdown for a while now.
I like how this is presented to be ludicrously compact, but it uses double quotes "" instead of single quotes ''.
Everybody knows that single quotes take up less space!
If you're really looking for efficiency, take a look at baconification ;)<p><a href="http://pastebin.com/RGRfewBY" rel="nofollow">http://pastebin.com/RGRfewBY</a><p>...comes in handy for those occasions when the courts order you to hand over some data - especially effective when printed.
For anybody who wants a little bit more structure than LCON but less clutter than JSON, I'd recommend checking out CSON.<p><a href="https://github.com/bevry/cson" rel="nofollow">https://github.com/bevry/cson</a>
For another compact format (exclusive to homogenous collections), checkout JSONH <a href="https://github.com/WebReflection/JSONH" rel="nofollow">https://github.com/WebReflection/JSONH</a>
I'm waiting for ubjson <a href="http://ubjson.org" rel="nofollow">http://ubjson.org</a> which is probably the most compelling json replacement I've seen yet.
How does this compare to JSON when gzipped? I imagine any size benefit of stripping colons and parenthesis is negligible compared to a good compression.