Odd behaviour with certain property assignments

[Alhadis]

Parsing this:

{foo: 2; @bar: 3} # CSON

... quite literally results in "this":

{a: 2, this: 3} // JS

It's also possible to use equals signs for assignment within curly braces, even though CSON docs state that variable assignments aren't allowed in CSON data:

{foo: 2; bar = 1 } # CSON

{foo: 2, bar: 1} // JS

I know cson-parser uses coffee---------script for lexing/parsing, so it's no surprise that some vestiges of its old class syntax are still hanging around. Even so, these constructs should ideally be considered invalid by the parser.

[jkrems]

Nice find! Thanks for reporting this. Agreed - neither of those should be allowed. I assume it should be possible to exclude them by looking more closely at the AST nodes.

[Alhadis]

Another oddity I've encountered: the following (presumably legal) syntax coughs up an error:

[### aaaa ### a: 2, 
Block: "comment"
]

CSON parser:

[stdin]:1:16: error: unexpected :
[### aaaa ### a: 2,
               ^

However, running the CSON snippet above in a CoffeeScript REPL shows what I expected to see:

[{/* aaaa */ a: 2, Block: "comment"}];

I'm still trying to work out how CoffeeScript handles overly-long # comments like this:

#########
Commented?
### End-of-comment?

The sample above yields puzzling errors from both CoffeeScript and cson-parser:

CoffeeScript REPL:

#########
Commented?
### End-of-comment?

cson-parser:

[stdin]:3:1: error: unexpected #
### End-of-comment?
^

[Inve1951]

Only an exact amount of 3 # open/close a block comment - everything else is a single-line comment.

Just wanted to drop this heads-up: CS is currently undergoing heavy changes in regards to AST generation: coffeescript/ast