satyr / coco

Unfancy CoffeeScript
http://satyr.github.com/coco/
MIT License
497 stars 48 forks source link

Cascade reference breaks inside implicit call #170

Closed qqueue closed 12 years ago

qqueue commented 12 years ago
thing
    fn &

throws Error: Parse error on line 2: Unexpected 'DEDENT', but

thing
    fn(&)

compiles as expected:

var x$;
x$ = thing;
fn(x$);
satyr commented 12 years ago

Not sure if we {c,sh}ould fix this since & is primary the good ol' binary operator.

$ coco -bcs
  fn &
     n

fn & n;

The length star * behaves likewise:

$ coco -bce 'a[f *]'
Error: Parse error on line 1: Unexpected ']'

$ coco -bce 'a[f(*)]'
a[f(a.length)];
qqueue commented 12 years ago

I suppose it's an argument in favor of livescript's choice of .. for the cascading operator.

thing
    ..stuff
    fn ..
    other thing ..property.method!

Doesn't look too bad IMO, and fits in with the backcall notation:

<- fn stuff, ... , other
satyr commented 12 years ago

"Can't be the first argument of an implicit call" is a weak reason for a symbol change that involves backward incompatibility. You can always use:

fits in with the backcall notation

Seems irrelevant to me.

qqueue commented 12 years ago

Weak, yes, but still an argument for a different symbol. In regards to backward incompatibility, the usual argument applies (the compiled js will still work).

Also, FWIW, Dart also chose .., so coco is the odd man out (of n=3, anyway).

I'm not terribly hung up about this problem, but I still think its important to consider all the implications of the symbol choice, and changing the operator sooner rather than later will be less likely to break code.

If only there were more symbols to work with :(

satyr commented 12 years ago

Dart also chose ..

Dart's cascade as shown there has largely different semantics than ours. Good thing we use different symbol.

its important to consider all the implications of the symbol choice

Sure. Off the top of my head .. has at least two major issues:

vendethiel commented 12 years ago

Can't you check if it's a member-access-like ? (which makes me think it's strange that gkz chose .. since it would not conflict with .&. EDIT : oh right, conflicts with ls's @@, aka & ...)

satyr commented 12 years ago

Can't you check if it's a member-access-like ?

Probably possible. But it wouldn't be enough since & can be stand-alone.

qqueue commented 12 years ago

Would it be possible/worthwhile to try reparse & as the cascadee in cases where parsing it as binary "AND" throws a syntax error? Kind of like vanilla JS's approach to ASI, I guess.

satyr commented 12 years ago

We'd have to disable the auto-line-continuation after bitwise &. Then:

a &
b &
  c &d

might be parsable as:

a(&)
b(&)  # cascading
  c(&.d)

rather than:

a & b & c & d

Intuitive enough?