parser: Enable late typing of composite literals

[juliaogris]

Enable late typing of composite literals, such that [1] can be []num or an []any depending on what is required by the assigned
variable, parameter or return type.

This finally allows for an evy implementation of a function like font
which accepts and {}any to call as: font {size: 4}.

[github-actions]

firebase-deployment: https://evy-lang--174-goi2atcg.web.app (e603b1d)

[camh-]

🥦 This is ok for now, but for me the code in type.go with Accept, Matches, acceptLiteral and acceptStrict has gotten to the point where I can't make a lot of sense of it any more. I think it all needs some thought about unifying parts of it where possible. It logically seems sensible that Accept() would be at least partially implemented by calling Matches() and there perhaps should be just a few additional cases to deal with literal conversion and generic collections.

But I don't have the mental bandwidth this Saturday morning to figure this out. If you don't get around to merging this right away I might give some thought to that unification.

[juliaogris]

🥦 This is ok for now, but for me the code in type.go with Accept, Matches, acceptLiteral and acceptStrict has gotten to the point where I can't make a lot of sense of it any more. I think it all needs some thought about unifying parts of it where possible. It logically seems sensible that Accept() would be at least partially implemented by calling Matches() and there perhaps should be just a few additional cases to deal with literal conversion and generic collections.

Yeah, I sadly have to totally agree. Barnacles.

I leave the PR open for now.

[camh-]

Thinking about this in the context of the panic of assigning a different type to an element of an any collection, I think this PR might be incomplete in that it checks that a []num literal can be used when an []any is wanted, but it does not change the type of the literal to []any. I think if it did this, then the fixup for the assignment issue might get solved automatically.

[juliaogris]

Thinking about this in the context of the panic of assigning a different type to an element of an any collection, I think this PR might be incomplete in that it checks that a []num literal can be used when an []any is wanted, but it does not change the type of the literal to []any. I think if it did this, then the fixup for the assignment issue might get solved automatically.

Well, something's broken, I'd agree there. FWIW

a:any
a = ["a" true]
a[1] = 1
print a

also panics, even though it gets assigned an []any array - something more fundamentally is broken here. I will wait for the other fix before merging this maybe.

[juliaogris]

This is also broken:

a:[]any
a = [1]

[juliaogris]

This comment should be addressed here I think:

#179 (comment)

[juliaogris]

#206 is covering this now.