Major oversight: tuple varargs lead to overloading ambiguities

[jmaessen]

Consider the mapping constructor:

opr {|->[\Key,Val\] xs:(Key,Val)... }:Map[\Key,Val\]

We already know that we can't invoke this with no arguments, and we must instead provide a 0-arg definition of opr { }. All well and good. What happens if we invoke this with a single mapping as an argument?

x = { "Snoopy" |-> 17 }

It appears that the interpreter flattens the call, and leaves it flat. I had thought there was a compensating path that tried a tupled call if a non-tupled call failed, but evidently this doesn't quite DTRT. Meanwhile, I believe this overloading for maps is fundamentally ambiguous. How do we distinguish the following two calls?

{ ("Hi",3) |-> ("Lois",23) }
{ "Hi" |-> 3, "Lois" |-> 23 }

The only obvious answer that comes to mind is that we must restrict map keys to Objects, thus preventing the use of tuples as map keys. Right now the interpreter always assumes it has a call of the latter form, and some explicit type instantiation seems to help keep things clear in any case.

See source:trunk/ProjectFortress/not_passing_yet/mapConstants.fss.