disambiguating parentheses are ambiguous

[pigworker]

One of the abiding design principles of our syntax is that the juxtaposition of two valid expressions is never a valid expression. That's how come we can write lists like

[e1 e2 e3]

Except that I broke this principle horrendously by allowing parentheses for disambiguation.

[(e1) (e2) (e3)]

is currently a one element list computed by iterated application.

With infix operators, that's bound to happen.

What does

foo (x + y) * z

mean?

The easiest fix is to change the principle to "no two valid expressions separated by whitespace ever constitute a valid expression", while insisting that application allows no whitespace between the function and the opening paren of its arguments. i.e.

e1 (e2)

is two things, but

e1(e2)

is one.

But perhaps there are other ways out of this rat sack.

[gallais]

I assume the same applies to clauses?

{ []  z -> e
  (y) z -> f
}

could be parsed as [] z -> e(y) & z -> f.

Earlier we dropped the | separator between clauses because the grammar
was unambiguous. Maybe it's time to bring them back (& similarly to move
to comma-separated list literals instead of the space separated ones?).

[pigworker]

Yes, it is no longer obvious where one clause ends and another begins, without some disambiguation policy.

I can live with | between clauses (although it does make a mess of #44). I'd be sad to see

['node ['node 'leaf 1 'leaf] 2 ['node 'leaf 3 'leaf]]

become

['node, ['node, 'leaf, 1, 'leaf], 2, ['node, 'leaf, 3, 'leaf]]

But indeed, that's an option.

[pigworker]

As I said on slack, allowing comma-separation doesn't bother me; requiring it does.

The no-space-between-fun-and-open-paren plan excludes styles like

myfunction
  ( arg1
  , arg2
  , arg3
  )

but perhaps we could allow a more spaced out presentation at the cost of being explicit

myfunction @
  ( arg1
  , arg2
  , arg3
  )

Kicking stuff around...

[pigworker]

I've implemented 7d66d15 as a holding pattern.

[pigworker]

I have now pushed a liberalization, allowing

[e1, e2, e3]

and

{p1, p2, p3 -> e}

but also their just-whitespace variants.

My preference would be for whitespace in lists and commas between arg patterns in abstractions. But I'm ok with diversity.

I didn't allow

f(e1 e2 e3)

instead of

f(e1, e2, e3)

but perhaps we should?