Break listar compat to always mean array (or remove it)

[vendethiel]

Yay #1000!

---

We really need to fix listar, it's been unintuitive for too long.

a =
 * b

should not mean a = b.

The offending code is here: when we see a * not in the middle of an expr, we add void =.

The code then parsing it is here, where Arr.maybe discards the Array-like structure for a single element.

I could see something like (parsing * as LISTAR):

ListarList:
  o 'LISTAR Expression' -> [$2] # we might want an OptComma here
  o 'LISTAR Expression NEWLINE' -> [$2]
  o 'ListarList NEWLINE LISTAR Expression' -> $1 ++ $4
  # contrarily to ArgList, I don't think we want a `ListarList NEWLINE INDENT ListarList DEDENT` rule.

# in Expression:
        o 'Chain ASSIGN INDENT ListarList OptComma DEDENT'
        , -> Assign $1.unwrap!, $4, L 2 Box $2

with that, we get:

a =
  4
# var a; a = 4;

b =
 * 4
# var b; b = [4];

c =
 * x:
    * 5
# var c; c = [{x: [5]}];

[rhendric]

At the very least, this should go through a deprecation release before the change is made.

Would you also want to change the related ‘surprise’

->
  * foo: 0
  * bar: 1
# function(){ ({ foo: 0 }); return { bar: 1 }; }

?

[vendethiel]

I think the proposed grammar would fix this "surprise". But yes it needs to be a test case.

[vendethiel]

Of note: the ArgList INDENT ArgList DEDENT rule is mainly for this use case:

[ a
  b
  c ]

And other similar cases.

[rhendric]

Another question is whether

[
  * a: 1 b: 2
  * c: 3
]

would continue to be a list of objects, or whether you would make it a list of a list of objects.

[vendethiel]

or whether you would make it a list of a list of objects.

That's a good question. Definitely a breaking change if we pick the latter.

It's still possible, though ugly, to separate the implicit objects in this case:

[
  a: 1
  b: 2
,
  c: 3
]

Seeing how bad that looks, I guess we should pick the former?