The parser allows the following thing, but the meaning is not clear

class Test
{
  Void main()
  {
    Obj:Obj:Obj jep := [:]
  }
}

A map of maps, seems to be.

C:\>fansh
Fantom Shell v1.0.51.1 ('?' for help)
fansh> Str:Int:Float mapmap := ["a":[1:2f]]
[a:[1:2.0]]

I don't know whether that syntax is worthwhile or not, I generally use the brackets so as not to confuse myself. Like tcolar mentioned, it certainly confuses the parser.

I had to look it up to, but it's well specified. (ML- and Haskell-like languages do stuff like this all the time).

In the case of :, the values are right associative, meaning A:B:C is the same as A:(B:C). That means if..

• map has type A:B:C
• a has type A, and
• b has type B

then map[a] has type B:C and map[a][b] has type C.

Of course, well-written code should always make the associativity explicit for those not familiar with this rule.

May be I missed something in the docs, but I was not able to find it. I found that this one is also possible which should not be possible.

Obj? :Obj jep3 := [:]

So if it would be right associative what should the compiler do in case we have

A:B?:C

I'm not sure exactly where you're getting A:B?:C. Did you type it correctly? (I looks like you maybe made a typo).

This might something to put into the docs -- a page on type constructors in Fantom explaining the grammar and semantics for list types, map types, nullable, and FFI types.

A:B:C a legal statement which is interpreted as \[A:\[B:C\]\] So A:B?:C while be interpreted as \[A:\[B?:C\]\] which is illegal. Theoretical the compiler could infer is would mean \[\[A:B?\],C\] which would be legal. I do not think is would be good idea to do inference, but just would like to mention it so other can give there opinion about it.

I would like to note that the compiler currently allows:

A? :B

with space between the ? and : which it should not allow.

Promoted to ticket #1060 and assigned to brian

I will go thru and beef up test suite to make sure some of these ambiguous cases are handled

I will just mention thread 442 wrt map type syntax (and note that the D language uses the proposed clearer syntax)

Renamed from map type ambiguity to Ensure Map types don't have nullable keys

Ticket resolved in 1.0.53

I think Jesse's main issue here isn't A:B:C which parses fine and is right associative. That all seems to work fine to me.

The issue is that the parser explicitly disallows nullable key types for Map signatures:

Str?:Str    // has always been an error
Str? : Str  // with space we used allow it and let it slip

I fixed the compiler to report an error with or without the space.