Syntax overview

[Jasper]

I can't find a good overview of what the syntax is? I worry a bit that
it grows too 'organically'. Surely what syntaxes are and what `Expr`
tree they produce should be clear to metaprogrammers, beyond inspecting
what actually happens?

Personally i would prefer if there were just a couple of simple(and
documented) ways syntax builds `Expr` trees.

1. 'M-expressions', basically how functions are written `f(x,y,..)`
(overriding `,` as an infix)

2. `begin ...end` and similar for `for`, `while`, `function` etcetera.

3. Infix notation. There was an github issue about basically allowing
arbitrary names for infix. I am personally against that but it should
probably work like that internally, and the same on each
operator. Currently `:(x+y+z)` is different than `:(x|y|z)` in more
ways than it should;(imo) the difference should be just `+` to `|`.

4. Order of operation stuff, parenthized expressions without commas to
make it a tuple `(...)`

5. Lack of infix symbol, currently seems to imply to use
`call`.(do `:([2 3]([3,1])).head`) But `x=(1,2); + x;` doesn't work,
neither does `+(x)` But i guess it does make sense, as a function can
return a function and you may want to call it. (Note that the
short way of writing anonymous functions also uses infix, `->`)

6. Macro notation `@a_macro ... ...` newlines get you out of the macro,
and you need to have given enough arguments by then. They're nearly
first-class-citizens. Nearly, because unlike point 2 it doesn't get to
own a `else`, `elseif` and `end`. But i am fine with nearly.

But continuing, it seems to be getting to crowded?

7. https://github.com/JuliaLang/julia/issues/1288 with `do` blocks for
instance, isn't that just point 2, but with a strange change of order?
The location of `do` seems to have more to do with how you speak it than
programming.

8. Stuff like `[println(23) for i = 1:3]`, `comprehensions` though
that looks very convenient, it also falls under 2/6?

Also, what is the nature of point 2? They can be done with macros
(modulo notation) so maybe they should be considered 'standard library'
that gets a hand from the parsing?(I guess the users won't notice but
maybe a good way to treat it when implementing)