Map exploration

[mattbasta]

I've been compiling this list for a while and would rather keep it here, since I need to reboot my computer.

Once panics are implemented, the next big thing to do is implement maps. Functionally, maps don't need to be perfect for the first iteration, but ideally the syntax for map literals should remain fairly stable. Here's what the manual instantiation of a map would look like:

var m = new Map<string, int>(100);  # First param is initial capacity
m.set('foo', 123);
var y = m.get('foo');
var a = m.has('foo');

Additionally, I've considered adding a few new sugar operators:

var doesContain = m has 'foo'; # Similar to `in` but reversed
var value = m['foo'];  # [] operator overload

Literal syntax ideas:

• JS:

  var x = {foo: 'bar', 'abc': 'def', [1 + 2]: 'zap'};

• Python:

  x = {'foo': 'bar', 1 + 2: 'zap'}

• Go:

  var x = map[string]int {"foo": 123, "x" + "y": 456}

• PHP:

  $x = array('foo' => 123, 'x' . 'y' => 456);
  $y = ['foo' => 123, 'x' . 'y' => 456];

• Ruby:

  x = {'foo' => 123, 'x' + 'y' => 456}

[mattbasta]

Notes:

• I don't want to have identifier-keyed maps.
• => is gross when used inside maps, but I don't have a problem with =
• Maps will only ever support a single key type and a single value type at once. This means hashing doesn't have to turn into some convoluted nightmare. I quite like the approach ES6 uses where keys are hashed based on the object that they reference rather than the object's contents. While there is use in the approach Python takes with only allowing immutable keys, there are too many "gotcha"s and frustrations for new users. It also adds a lot of overhead to the compiler, since immutability needs to be determined at compile time, and that's not necessarily possible (the immutability stuff that was originally implemented was thrown out because it was a bad idea). The benefits of an ES6-style Map seem to far outweigh a vanilla Python dict's pattern-matching sort of approach.
• The type of a map should always be inferrable, so it should require no additional type annotation.

WRT the last point:

• If we support computed keys by default (we should) then the type of any expression should be computable, except when type backpropagation is used (e.g., in the case of lambdas).
• Regardless, using a key would have the same type inference as, say, the r-value of an assignment.