Enhancement: possible solution to the Array-Literal-Without-Brackets problem

[shanebdavis]

Coffeescript streamlines syntax: In most cases, closing symbols are not needed, and in most cases lists can be delimited with commas, newlines or both.

Coffeescript has two significant inconsistencies:

Inconsistency 1: array literals require start and end brackets

myArray = [
  1
  2
  3
]
# -> myArray = [1, 2, 3];

Many solutions to the array problem have been discussed: #645, #1190, #1702, #1872, #2259, #2642, #3115

Inconsistency 2: multi-argument function invocations require at least one comma

myFun 1,
  2
  3
# -> myFun(1, 2, 3);

I did not find any discussion of this problem. Why isn't the following legal?

# ERROR ON LINE 2: UNEXPECTED INDENTATION
myFun
  1
  2
  3
# should generate: myFun(1, 2, 3);

If that WAS legal, then @TrevorBurnham's suggestion in #1872 would be a reasonable solution to the array problem:

Use a function: arr = (args...) -> args

Then we can write bracket-less arrays like this:

myArray = arr
  1
  2
  3    
# -> myArray = [1, 2, 3];

The only problem I've found so far are ambiguities like:

if arr
  1
  2
  3
# is it this: if (arr) {1; 2; 3;}
# or this:    if (arr(1,2,3)) ...

It seems reasonable to disambiguate those scenarios by choosing the current, backward compatible interpretation. Anytime an indented block is legal, multi-line function invocations require explicit () or a comma after the first param - as it does currently.

Thoughts?

These two problems significantly limit both declarative programming styles and embedded DSLs. I'd really like to find some solution.

[jashkenas]

I think you more or less answered your own question.

If, as you suggest:

request
  transform url
  twiddle options

Compiled into:

request(transform(url), twiddle(options))

But:

if request
  transform url
  twiddle options

Compiled into:

if (request) {
  transform(url);
  twiddle(options);
}

... that would be pretty horrible, and would make our syntax surprising and difficult to compose in a straightforward way.

[shanebdavis]

"... that would be pretty horrible, and would make our syntax surprising and difficult to compose in a straightforward way."

Why? It doesn't seem horrible or overly surprising to me. Can you give a more concrete example of why you think it is bad? The above example looks completely reasonable to me.

[xixixao]

if request
    transform url
    twiddle options
  do something

if a +
    b
  c

It would be interesting to see more examples, this would be really handy in some cases (DSLish). Whether this would be parseable at all is another question (coco doesn't seem to support this either).

[vendethiel]

Coco uses do for block arguments (and then for the body)