Enhancement: Pretty multiline array's using splat prefix syntax

[m1sta]

The closing bracket current required when defining arrays over multiple lines leaves me feeling like I'm living in the past. I propose a splat prefix that allows something like this...

myTable = ...
    ...
        firstItem
        secondItem
        thirdItem
        ...
            fourthItem
    ...
        fifthItem
        sixthItem

... instead of having to write

myTable = [
    [
        firstItem
        secondItem
        thirdItem
        [
            fourthItem
        ]
    ]
    [
        fithItem
        sixthItem
    ]
]

Ideally the first splat could be excluded if we were smart enough to see that what was preceding was a function call nor what was to come was an object literal. This would leave...

myTable = 
    ... firstItem
        secondItem
        thirdItem
        ... fourthItem
    ... fifthItem
        sixthItem

[davidchambers]

> python -c 'import this' | grep only
There should be one-- and preferably only one --obvious way to do it.

-1

[m1sta]

Array's are used in more than one way though. Just like we allow object literals to be defined in two ways depending on context, allowing arrays to be defined in two ways need not be overly confusing. Array's of lambda functions are the best example of where I think this would be useful.

[epidemian]

I'm with @davidchambers here. My comment on the other proposal about not overloading syntactic symbols applies here too. The ... symbol already has two very different meanings, which is unfortunate i think: the "splat" operator and the non-inclusive range operator.

Brackets are a pretty good and standard way of denoting arrays. Let's use them!

[m1sta]

Fair call about not using the 'splat' operator, but isn't one of the nice things about coffeescript the fact that you don't need to use brackets in most instances?

[epidemian]

Fair call about not using the 'splat' operator, but isn't one of the nice things about coffeescript the fact that you don't need to use brackets in most instances?

I think what makes CS's syntax nicer than JS's is that it's lighter in many cases. For instance, it doesn't use braces to denote blocks. But that case is different from using implicit symbols, e.g. implicit braces for object literals, because the braces are still there syntactically, you just can't see them, but you have to remember them, or else they can bite you:

$ coffee -ce 'foo bar:'
[stdin]:1:8: error: unexpected }
foo bar:
       ^

$ coffee -ce 'foo(:42)'
[stdin]:1:4: error: unexpected {
foo(:42)
   ^

These implicit syntactic symbols will also bite you on the "empty" cases. You may be brace-free in all your code, with beautiful object literals like foo: 42, bar: 77, but as soon as you need an empty object, wah waaah, you'll need those nasty braces: {}.

[m1sta]

Would you advocate removing the existing implicit syntactic symbols that already exist in Coffeescript?

I agree that the inclusion of them in the design of a language definitely comes with some 'challenges' but given that they are already prolific I'm not sure that this broad level counter-argument to their use in the context of array definitions is particularly strong.

As it stands now, I simply use a tiny helper function to allow the following. It's not fast but I find it easier to read/write when I see heavily nested arrays (no tracking of closing brackets)...

myTable = 
   array
     1:"hello"
     2:"world"
     3:array
        1:"My"
        2:"name"

[epidemian]

Would you advocate removing the existing implicit syntactic symbols that already exist in Coffeescript?

I don't see that happening, but it'd be nice if some of the more problematic cases would be revised in the future. Breaking backward compatibility is never fun; but i think it can be done in a sensible manner.

I agree that the inclusion of them in the design of a language definitely comes with some 'challenges' but given that they are already prolific I'm not sure that this broad level counter-argument to their use in the context of array definitions is particularly strong.

I'm sorry, but that sounds like broken window thinking to me: "given that the grammar is already littered with 'challenges', why not add a few more?". I'd prefer to consider remedying those challenges, and make the grammar as easy to understand as possible.

As it stands now, I simply use the following helper function (it's not fast but I find it easier to read/write in some circumstances)...

I think that's a very high price to pay just to get rid of brackets. Maintaining that code will be difficult. Want to add or remove an element in the middle of the array? Then remember to change all the following index numbers. Tedious merge conflicts guaranteed.

[vendethiel]

Closing as a duplicate of #645 and a lot of others