Fully Qualified Names are not allowed in type signatures

[radeusgd]

Repro:

from Standard.Base import all

foo : Standard.Base.Data.Numbers.Integer
foo = 1

bar (x : Standard.Base.Data.Numbers.Integer) = 10+x

main =
    bar foo

This seems like a completely valid program, but it fails to compile with:

X:\NBO\repr\test3.enso:3:7: error: The name `Standard.Base.Data.Numbers.Integer` could not be found.
    3 | foo : Standard.Base.Data.Numbers.Integer
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X:\NBO\repr\test3.enso:6:10: error: The name `Standard.Base.Data.Numbers.Integer` could not be found.
    6 | bar (x : Standard.Base.Data.Numbers.Integer) = 10+x
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aborting due to 2 errors and 0 warnings.
Execution finished with an error: Compilation aborted due to errors.

If I replace the FQNs with just Integer it runs all fine.

I don't see any reason why FQNs should not be allowed in type signatures. In fact it is rather confusing.

Note that the exact same FQN used as value works all fine:

from Standard.Base import all

main =
    IO.println Standard.Base.Data.Numbers.Integer
    IO.println (42.is_a Standard.Base.Data.Numbers.Integer)

printing

Integer
True

[Akirathan]

Note that the exact same FQN used as value works all fine:

The reason it works in that case is that the fully-qualified name in the snippet

main =
    IO.println Standard.Base.Data.Numbers.Integer
    IO.println (42.is_a Standard.Base.Data.Numbers.Integer)

is resolved at runtime. Whereas the fully-qualified names in type signatures are resolved during compilation. More specifically, in the TypeNames compiler pass. I was able to pinpoint the exact failure in resolution in BindingsMap. See #12263 (comment)

[JaroslavTulach]

Enso always wanted to support dependent types...

is resolved at runtime. Whereas the fully-qualified names in type signatures are resolved during compilation.

... to simplify: there is no difference between value and type treatment. Why not resolve the FQN at runtime as well?

[radeusgd]

Enso always wanted to support dependent types...

is resolved at runtime. Whereas the fully-qualified names in type signatures are resolved during compilation.

... to simplify: there is no difference between value and type treatment. Why not resolve the FQN at runtime as well?

Because where possible we still want to do static analysis, no?

If I can resolve something at compile time, I can report an error to the user and find typos much faster. Deferring to runtime may even cause such errors to be completely unnoticed if a relevant test does not cover enough execution paths.

[Akirathan]

Why not resolve the FQN at runtime as well?

In addition to what @radeusgd already mentioned, all the necessary information is already present in BindingsMap at compilation time, we are just not using it in this case.

[JaroslavTulach]

Because where possible we still want to do static analysis, no?

I am not 100% sure and I don't think I ever claimed that or agreed to that.

If I can resolve something at compile time,

It may slow down the start...

Deferring to runtime

...may speed startup significantly.