Mid-statement indention support.

[ScatteredRay]

So, in continuing effort to get more existing CoffeeScript to compile, I'd like to discuss the problem of INDENT tokens happening mid-stream, and similarly matching DEDENT tokens happening after the statement:

x = [1, 2,
       3, 4]

This would look something like this in the token stream (excuse my liberal making up of token names, but there doesn't seem to be a well specified formal def):

['x', EQ, '[', '1', '2', INDENT, '3', '4', ']', 'DEDENT'

Whereas the rest of the compiler likes to handle INDENT, and DEDENT much like standard matching pairs, and would much prefer something like:

['x', EQ, '[',  INDENT, '1', '2', '3', '4', 'DEDENT', ']'

Can we agree that this is a valuable thing to solve? If so, is there an elegant solution, are there any particular cases that we want to ensure are actually errors?

It seems that Python may just ignore the first set of indentation inside multi-line matching pairs.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[michaelficarra]

I know it's going to be unpopular, but this looks like yet another duplicate of jashkenas/coffee-script#1736. In python, indentation inside parentheses or brackets is ignored. CoffeeScript isn't python. Indentation is significant everywhere.

[ScatteredRay]

I don't think this is the the same issue... While it is indeed correct that

x = {1: 2,
     3: 4}

does not compile in coffee, this does:

x = [1, 2,
     3, 4]

I agree that CoffeeScript isn't nor should be Python, But I think it's important to match existing CoffeeScript behavior if can be done so reasonably. I think this is a case where it can be done so reasonably.

[vendethiel]

Maybe the first one should for consistency with the second, but implicit objects.

[ScatteredRay]

@Nami-Doc Perhaps, but I'm not sure it's nearly as unambigious with nested objects and all.

[ScatteredRay]

This case seems to be ambigious enough:

f = (v) ->
  v

x = a: f
      b: 2

[ScatteredRay]

Interestingly enough, the original compiler compiles:

f = (v) ->
  v

x = [a, f
     b, 2]

as

var f, x;

f = function(v) {
  return v;
};

x = [a, f, b, 2];

And I don't know if that's good or bad.

[vendethiel]

Bracket and parens rules are already really complex and break a lot in coffee Ie :

foo
  {a: 1}
  {b: 2}
  {c: 3}

Won't parse because addImplicitParentheses will not trigger implicit call if you have INDENT {.

As for the compile result that's what I'd expect.

[ScatteredRay]

I agree they they are terribly convoluted, Perhaps you know of a few more coffee-script bugs that are caused by this so we can write test cases, so if we do choose to fix this we can do it properly?

regarding the compile result, I could agree, but compare it to how coffee compiles the comparitive object:

f = (v) ->
  v

x = [a, f
     b, 2]

y = {a: f
     b: 2}

as

var f, x, y;

f = function(v) {
  return v;
};

x = [a, f, b, 2];

y = {
  a: f({
    b: 2
  })
};

My point to was to bring up that it's not nearly so clear-cut. In response to supporting the prior like the later.

[vendethiel]

This is an edge case of implicit objects, not implicit call. Merely everything I know concerning comes from @satyr. I could certainly find issues tho (after my cinema tho :p). Which makes things like that fail :

{a: b,
  c: d}

Which is basically the same case as yours but with a comma.

[ScatteredRay]

I think that'd be valuable, Because I think there may be a reasonable solution to this problem that doesn't cause problems elsewhere, but better tests will make that much easier.

[jldailey]

Allowed, but terrible:

Math.min [
    a,
    b
]...

Not allowed, but obvious and natural:

Math.min(
    a,
    b
)

???

[michaelficarra]

@jldailey: It's known. See #57.