The thing is, I’m also dyslexic , and for me at least:
xs.map x =>
...
// reads as:
(xs.map x) =>
// (Of course, this makes no sense, but it's not the logical part that does the intuitive reading)
...
The reason being that =>
is a “strong separator”, whereas there’s no separator between map
and x
, by adding :
, we explicitly add a separator, which makes the parsing way easier (for me):
xs.map: x =>
...
(I have the same issue with the extension syntax, hence why I proposed E6 and E7)
Of course the main problem is that :
already has two really distinct meanings, one in typing, and the other in introducing “bodies”, so there’s only two options:
- Keep this ambiguity and adapt as much as possible (imo this spells trouble in the long term)
- Remove this ambiguity by using two different symbols (or potentially keywords, but I’m not in favor)
Finally, the if
question, I’m strongly against this:
if c: a else b
//parsing as
if c {a} else b
//instead of (even tho this makes "no sense")
if c {a else b}
- The
then
is already a perfectly fine and flexible solution
- This would be an exception to my description of colon-bloc syntax, as we now need to lookahead to know where the bloc ends (see below)
- The above makes it harder to develop parsers for scala which affect both the compiler, and even more importantly tooling (for example a simple regex* is no longer sufficient to swap between syntaxes)
// cannot simply go forward until finding the first "else"
if c1: if c2: e1 else e2 else e3
*it would need to know about indents, but the language is regular modulo that
Yes, my proposal allows single line lambda without parentheses, see P2, E1
The other very important advantage is that it can become the rule for all braceless syntax with a very simple tweak:
"Braces can be dropped if
- the bloc is correctly indented, and
- the opening brace follows a keyword, or is replaced by
:
"
(There’s probably cases I’m missing, do point them out)