Closed qqueue closed 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)];
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
"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.fits in with the backcall notation
Seems irrelevant to me.
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 :(
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:
@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'
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 & ...)
Can't you check if it's a member-access-like ?
Probably possible. But it wouldn't be enough since &
can be stand-alone.
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.
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?
throws
Error: Parse error on line 2: Unexpected 'DEDENT'
, butcompiles as expected: