Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cascade reference breaks inside implicit call #170

Closed
qqueue opened this issue Oct 3, 2012 · 9 comments
Closed

Cascade reference breaks inside implicit call #170

qqueue opened this issue Oct 3, 2012 · 9 comments

Comments

@qqueue
Copy link

qqueue commented Oct 3, 2012

thing
    fn &

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

thing
    fn(&)

compiles as expected:

var x$;
x$ = thing;
fn(x$);
@satyr
Copy link
Owner

satyr commented Oct 3, 2012

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
Copy link
Author

qqueue commented Oct 3, 2012

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
Copy link
Owner

satyr commented Oct 3, 2012

"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:

  • (&) to force cascadee.
  • an explicit variable on complex use cases like that.

fits in with the backcall notation

Seems irrelevant to me.

@qqueue
Copy link
Author

qqueue commented Oct 3, 2012

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
Copy link
Owner

satyr commented Oct 4, 2012

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:

  • We need to find another symbol for the constructor shorthand. @constructor.staticProp is too long.

  • It's two characters. Being one character symbol is important since using one character variable already achieves the same effect with two characters:

    node.style |> do
      _.background = 'red'
      _.border = '2px solid black'
    

@vendethiel
Copy link
Contributor

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
Copy link
Owner

satyr commented Oct 4, 2012

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
Copy link
Author

qqueue commented Oct 4, 2012

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
Copy link
Owner

satyr commented Oct 16, 2012

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?

@satyr satyr closed this as completed in 1088b22 Oct 17, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants