RFC: regularize Dict syntax

[JeffBezanson]

This provides Dict(a=>b, c=>d, ...) and Dict{K,V}(a=>b, c=>d, ...) syntax. Plan is to deprecate other dict syntax.

Fixes #6739.

I think the main controversy is what exactly => should be. Right now it is special syntax for a call to Base.Pair. It could be a function, or the name of the pair type (immutable =>{A,B}).

[vtjnash]

I think => implies a relationship that should be reflected in the name. Pair seems too generic, and just descriptive of the process of making any two-tuple.

let the name bikeshedding begin!

How about:
KeyValue (my favorite)
KVPair
KeyValuePair

[JeffBezanson]

Making => the name of the type is a good way to avoid that problem.

[JeffBezanson]

Ready to merge pending travis.

[StefanKarpinski]

Exciting!!

[vtjnash]

Missing actual construction of Dict here?

[JeffBezanson]

Dict comprehension syntax has not been deprecated yet, since we don't have an efficient replacement. It will be Dict( i => f(x) for i = 1:10 ). However the old syntax at least has to keep working (with a warning) through 0.4.

[Jutho]

You decided to keep => as a synonym to Pair and not make it a type of its own?

[StefanKarpinski]

This separates the syntax (=>) from what it constructs (Pair). I suspect this is a good choice.

[JeffBezanson]

Yes. The best part is that => now parses like any other operator, so it is generally available. Then I aliased it to Pair. This way it would be easy to remove the aliasing and just call the type =>, but I figured it would look really bizarre to write stuff like p::=>{A,B}.

[quinnj]

I guess it could be name KeyValue if people feel uncomfortable with the name Pair being associated with the => operator. Though there's no special structure there, just pair.a and pair.b. Looking forward to this!

[eschnett]

This would read p::(A=>B) instead, which doesn't look that bad -- compare
to p::(A,B).

-erik

On Mon, Oct 6, 2014 at 2:43 PM, Jeff Bezanson notifications@github.com
wrote:

Yes. The best part is that => now parses like any other operator, so it
is generally available. Then I aliased it to Pair. This way it would be
easy to remove the aliasing and just call the type =>, but I figured it
would look really bizarre to write stuff like p::=>{A,B}.

Reply to this email directly or view it on GitHub
#8521 (comment).

Erik Schnetter schnetter@cct.lsu.edu
http://www.perimeterinstitute.ca/personal/eschnetter/

[StefanKarpinski]

Well, then we'd be repeating the whole tuple type business over again – does A=>B denote the pair of values A and B or the type of such pairs?

[StefanKarpinski]

How about calling the type Arrow and its fields .from and .to?

[Jutho]

I have no preference, =>{A,B} as type name would indeed be strange (unless it has some nice formatting). I just wanted to make sure that this was well thought through.

[jiahao]

Imagine having that conversation where you'd have to explain that the Arrow type is not an arrow type...

[JeffBezanson]

Yes, Arrow would be ok but "arrow type" is a well-established term for function types.

[StefanKarpinski]

But those very same people love category theory...

[StefanKarpinski]

Ok, I think that Pair is a fine name and I like .a and .b as field names.

[quinnj]

I think Pair is fine. The explanation is that a Pair is simply that, a pair of two objects. The fact that the => syntax is used is for convenience when using Pair objects with Dicts, not that the Pair type always implies some kind of direction or key-value relationship. I'm sure there will be uses of Pair in other places where the => doesn't make sense to use, so one can just use Pair(a,b).

[IainNZ]

Perhaps unsurprisingly, this broke everything - there was a delay though due to the PkgEval machine being down. Can someone who understands this better than I provide a snippet for explaining how to have the old and the new in the same code base?

[nolta]

Here's one approach: JuliaGraphics/Winston.jl@9f1d9c8

[garborg]

Another: Dict([("a", 1), ("b", 2)])

[simonster]

The reason this broke DataArrays despite the deprecation is that previously, if all keys were of type K but the types of the values differed, we got a Dict{K,Any}, but now if either the keys or values are not the same type we get a Dict{Any,Any}. With 0.3:

julia> [1 => 2, 2 => "a"]
Dict{Int64,Any} with 2 entries:
  2 => "a"
  1 => 2

with master:

julia> [1 => 2, 2 => "a"]

WARNING: deprecated syntax "[a=>b, ...]".
Use "Dict(a=>b, ...)" instead.
Dict{Any,Any} with 2 entries:
  2 => "a"
  1 => 2

Was this an intentional change? It seems easy enough to change it back by using the same pattern for the pair constructor as for the tuple constructor.

[JeffBezanson]

No, it wasn't intentional. Please change it back as you describe if you get a chance.

[simonster]

Also, while Dict{K,V}(ks::(K...), vs::(V...)) conflicts with the new syntax, is there any reason not to have a deprecation warning for Dict{K,V}(ks::AbstractArray{K}, vs::AbstractArray{V})?

[JeffBezanson]

We could actually have a deprecation warning for both. The only new >1 argument form of Dict accepts only Pairs.

[simonster]

Yeah, I realized that later and put deprecations for both in #8627

[IainNZ]

I'd say that there has been about 75% recovery already from the errors yesterday, a good chunk of the remaining are probably actually due to the removal of the range deprecations and are semi-abandoned packages.

[nalimilan]

Out of curiosity, why was a new Pair type needed, instead of simply creating a length-2 tuple? Performance?

[toivoh]

One motivation is to be able to distinguish between which syntax was used -
you might want a 2-tuple mean something different than a Pair.

[tonyhffong]

Could someone take a look at the languishing PR relevant for transitioning to 0.4? Yay or nay?

JuliaLang/Compat.jl#8