Add Dict comprehensions and typed Dicts -- alternative version (changes Dict literal notation)

[carlobaldassi]

This is an alternative version of my other pull request #1467, and it follows Stefan's proposal.

Under this framework, the rules for literal notations are more straightforward:

• using {...} will use the Any type
• using [...] will try to infer the type
• the [...] notation can be type-annontated to control the type explicitly
• if there is a => symbol anywhere, it's a Dict, otherwise it's an Array
• the type annotation for Arrays is T[...], for Dicts is (K=>V)[...]
• comprehensions are supported in all cases

[removed the following] Additionally, there is syntax for the empty Dict case: {=>}. The syntax [=>] is supported and gives a Dict(None,None) just like [] is a Vector{None}. The syntax (K=>V)[=>] is also supported for consistency, but it's equivalent to (K=>V)[]. [up to here]

There is no special literal syntax for the empty Dict{Any,Any} case; one would use either plain old Dict() or (Any=>Any)[].

Apart from this, everything else works like in #1467.

Notes:

• this is a breaking change, since {1=>2,3=>4} is no longer a Dict{Int,Int} after this change.
• this change is in strong contrast to the idea of using [...] for Arrays and {...} for Dicts (as said above, it's the => symbol which distinguishes them).

Personally, I strongly prefer this framework to the previous one.

[JeffBezanson]

Mostly in favor of this, but seeing {=>} used everywhere it looks exceedingly odd.

[carlobaldassi]

Just when I kind of got almost more or less somehow used to it!!
No seriously, it's clearly an outlier in the syntax (which is also demonstrated by how I had to force the parser to accept it). The pro's of it as I see them are: 1) it fits within the rules 2) it's as concise as you can get 3) it currently cannot be mistaken for something else (except for a syntax error :) ). Another issue (beyond oddity) is that this would prevent allowing => as a function name in the future, since then you wouldn't be able to tell {=>}::Dict{Any,Any} from {=>}::Vector{Function}.

So, I will now remove it; this will leave unsolved the issue of building an empty Dict{Any,Any} with literal notation (but then again Dict() is not such a bad syntax after all...). In case of a change of heart, reintroducing it is not a big deal.

Warning: wild speculation/random babbling ahead

A possible concern with this general framework (and with all others) is how to extend it to other containers (e.g. Mike mentioned Sets the other day). Apart from ugly, verbose & massively breaking changes, there is maybe one way which would be just ugly, namely putting an optional symbol just after the opening bracket, e.g. [=> 1=>2] for Dicts and maybe [|| 1,2,3] for Sets.
This would solve the empty container issue (e.g. {||} is an empty Set{Any}, Int[||] is an empty Set{Int}) and of specifying comprehensions (e.g. [|| f(i) for i in x] is a Set comprehension). One problem is that the syntax could get obscure. Another problem would be that without a separator this can only work with syntactical symbols, which cannot be mistaken as function names (e.g. [&] → no good), and this in turn means there's a limited set of symbols to choose from, and that once a symbol is taken it cannot be turned into a function any more. A separator might help to this end (e.g. [&: 1,2,3] should not be mistakable, but I'm not 100% sure), at the cost of even more ugliness ([&:]? seriously?).

[carlobaldassi]

Ok I removed the {=>} syntax.

[JeffBezanson]

Yes, Dict() is perfectly good syntax. It is certainly clear.

To extend this further, we might need to add new kinds of brackets, such as [| ... |]. Fortress does this kind of thing to make more of the notations extensible.

[JeffBezanson]

It's worth noting that ordinary calling syntax such as Dict{K,V}((k1,v1), (k2,v2), (k3,v3), ...) is pretty close to an acceptable notation already. If a=>b were sugar for (a,b) we'd basically have it. I can't decide whether that's a silly hack or not.